eb_element_cb
Eric Brown
I understand that the same eb_element_cb can be called several times
per datum. Do subsequent calls include all previous data? (Or am I
supposed to concatinate?)
I assume that once on_complete is called no more eb_element_cb
functions will get called for the current request?
These types of things are hard to test for -- sending small bits of
data.
Cheers,
Eric
ry dahl
On Tue, Aug 26, 2008 at 12:19 AM, Eric Brown <yogi...@gmail.com> wrote:
> I understand that the same ebb_element_cb can be called several times
> per datum. Do subsequent calls include all previous data? (Or am I
> supposed to concatinate?)
You should concatenate
> I assume that once on_complete is called no more ebb_element_cb
> functions will get called for the current request?
yes
> These types of things are hard to test for -- sending small bits of
> data.
Yes, but it allows for the user of the library to be optimally
efficient. The alternative is to, in one way or another, buffer the
data inside of libebb. This way libebb is really only doing parsing
and socket handling as best as it can and leaving all the "structure"
decisions to you. You're getting low level access to the server
internals while still getting relatively high level info.
I apologize for the lack of documentation. Reading
http://github.com/ry/ebb/tree/master/ext/ebb_ffi.c
for a "real life" example might be helpful. I will try to have more
documentation soon.
ry
Eric Brown
On Aug 25, 2008, at 3:53 PM, ry dahl wrote:
>
> Hi Eric,
>
> On Tue, Aug 26, 2008 at 12:19 AM, Eric Brown <yogi...@gmail.com>
> wrote:
>> I understand that the same ebb_element_cb can be called several times
>> per datum. Do subsequent calls include all previous data? (Or am I
>> supposed to concatinate?)
>
> You should concatenate
>
>> I assume that once on_complete is called no more ebb_element_cb
>> functions will get called for the current request?
>
> yes
>
>> These types of things are hard to test for -- sending small bits of
>> data.
>
> Yes, but it allows for the user of the library to be optimally
> efficient. The alternative is to, in one way or another, buffer the
> data inside of libebb. This way libebb is really only doing parsing
> and socket handling as best as it can and leaving all the "structure"
> decisions to you. You're getting low level access to the server
> internals while still getting relatively high level info.
Yes, of course. You're architecture is a fairly good fit for my
application as I have my own memory allocation, custom containers and
management of libev loops.
I also don't see any global or static data at the moment (other than
the connection buffer which I will override). Please don't add any if
you can avoid doing so as it will currently fit my threading model
very well.
BTW, that's the first time I've seen ragel - very impressive. I'm
going to try and figure out how to use it for my RFC822 header parsing
as well.
> I apologize for the lack of documentation. Reading
> http://github.com/ry/ebb/tree/master/ext/ebb_ffi.c
> for a "real life" example might be helpful. I will try to have more
> documentation soon.
No worries. I like how simple it is -- but so powerful too! Thanks!
Eric