> -----Original Message-----
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: dinsdag 10 november 2015 23:37
> To: 'Ivan Zhakov' <i...@visualsvn.com>; rhuij...@apache.org
> Cc: dev@serf.apache.org
> Subject: RE: svn commit: r1713489 - in /serf/trunk: buckets/event_buckets.c
> outgoing.c serf_private.h
>
>
>
> > -----Original Message-----
> > From: Ivan Zhakov [mailto:i...@visualsvn.com]
> > Sent: dinsdag 10 november 2015 20:43
> > To: rhuij...@apache.org
> > Cc: dev@serf.apache.org
> > Subject: Re: svn commit: r1713489 - in /serf/trunk:
> buckets/event_buckets.c
> > outgoing.c serf_private.h
> >
> > On 9 November 2015 at 20:49, <rhuij...@apache.org> wrote:
> > > Author: rhuijben
> > > Date: Mon Nov 9 17:49:59 2015
> > > New Revision: 1713489
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1713489&view=rev
> > > Log:
> > > Replace the track bucket in the request writing with a tiny bit more
> > > advanced event bucket that tracks both writing done and destroyed. The
> > > timings of these callbacks will allow simplifying some logic introduced
> > > in r1712776.
> > >
> > > For now declare the event bucket as a private type.
> > >
> > > * buckets/event_buckets.c
> > > New file.
> > >
> > > * outgoing.c
> > > (request_writing_done): New function.
> > > (request_writing_finished): Tweak to implement
> > serf_bucket_event_callback_t.
> > > (write_to_connection): Add event bucket directly after the request
> > bucket,
> > > instead of an aggregate when the writing is done.
> > >
> > Hi Bert,
> >
> > What do you think about alternative design for event buckets: make
> > event bucket wrap any other bucket (request bucket in our case)? I
> > think it will be more flexible since we could add callback to be
> > called before reading from wrapped bucket to track pending request.
>
> That might work, but would have different characteristics unless you do
> more special things.
There is one more problem with all this wrapping: All layers need to somehow
support all read methods.
Wrapping works for all methods except: readline.
This method is only implemented on a few bucket types, and doesn't allow
passing an upper limit to whatever is read... so things like limit and
unframing buckets can never implement this without implementing some caching...
And once they introduce caching all read methods need to look at the cache.
This problem is not that relevant for writing requests, as that reads raw data
anyway... but we are having more and more buckets that just set the readline
implementation to NULL.
Perhaps we can improve things a bit by adding an improved readline to the
buckets v2, but I'm not sure how yet. (Would passing a new max size argument be
enough?)
Bert
