C-K API

[Bakul Shah]

Now that the C-K API is commited and documented I think it is
time to note a few things.

* The C-K API has most of the function implemented.
Unimplemented features are tagged [NYI] in the
documentation.

* The document is pretty rough. Please let me know about
errors of any kind or if things are not clear. I was
undecided between whether to use k or kona and it shows.

* The primary interface is via kona.h. There is a bunch of
duplication between it and other header files that needs to
be removed to avoid problems in the future.

* Kona uses a lot of names that can conflict with a C client's
namespace. Ideally *no names* except the API visible ones
are exported. This is doable if all of kona was in one file
(IIRC that is how the first k version was implemented!). Or
we can include a list such as #define show k_show during the
library build.

* Ideally kona uses no globals so that the library is fully
reentrant (+ we can have multiple threads, each with
their own k interpreter!). May be some day?

[Neeraj Rai]

Hi Bakul,

looks good. the kapi.txt probably belongs on wiki page. Although it has some repetitions, it is a good end to end read.

Is the socket send deferred for now? Sending a dicts from my c code to kona server for saving would be quite beneficial functionality.

the example "avg" function in kapi.txt should return (a+b)/2. Currently, it returns (a+b).

thanks

Neeraj

[Bakul Shah]

On Tue, 28 May 2013 20:01:17 PDT Neeraj Rai <rneer...@gmail.com> wrote:
> Hi Bakul,
>
> looks good. the kapi.txt probably belongs on wiki page. Although it has
> some repetitions, it is a good end to end read.
> Is the socket send deferred for now? Sending a dicts from my c code to kona
> server for saving would be quite beneficial functionality.
> the example "avg" function in kapi.txt should return (a+b)/2. Currently, it
> returns (a+b).

Thanks for the feedback. I suppose I should've read it at
least once to discover repititions :-) Will fix the issues you
discovered.

I need to dig deeper into kona internals to complete the
unimplemented stuff.

[Neeraj Rai]

Hi Bakul,

I was not clear in my remarks. 

I didn't find repetitions in kapi.txt. Contents of kapi.txt repeated stuff from wiki. And that is preferred as it make it self contained.

I was specifically curious about sending K structs over sockets. Will wait for next version.

thanks

Neeraj

[Neeraj Rai]

Hi,

What are the pros and cons of following 2 approaches to getting data from my c program to kona ?

A. link my c code with kona lib and create K objects using kona memory pools.

     ship them to a running kona server using X or similar call. persist them in kona format

B. do not link my c code with kona lib. write my c structs in binary format to a file.

     write some kona shared lib code to load my structs and convert to kona format.

     save them in kona format.

My need to convert is not time sesitive  - I'll most likely need it at end of day in kona format.

B pros : avoids having to slow down my c program when converting to K objs. I do fwrite instead of socket send.

    cons : I need to write some more code for each struct to load it in shared lib

             I have 6 structs now and the number is not expected to grow beyond 10. For my use, it is not a big deal.

I would like to hear more thoughts about other use cases.

thanks
Neeraj

On Monday, 27 May 2013 16:11:32 UTC-4, Bakul wrote: