On 8 September 2014 at 13:03, Lieven Govaerts <l...@mobsol.be> wrote: > On Mon, Sep 8, 2014 at 11:57 AM, Ivan Zhakov <i...@visualsvn.com> wrote: >> On 7 September 2014 12:32, Lieven Govaerts <l...@mobsol.be> wrote: >>> On Mon, Sep 1, 2014 at 7:08 PM, Ivan Zhakov <i...@visualsvn.com> wrote: >>>> On 19 August 2014 12:39, Lieven Govaerts <l...@mobsol.be> wrote: >>>>> On Thu, Jun 26, 2014 at 1:14 PM, Ivan Zhakov <i...@visualsvn.com> wrote: >>> .. >>> >>>> Do we really need this feature? >>> >>> An application needs to know about the serf_config_t objects anyhow, >>> so it seemed useful to me to also offer its benefits to the >>> application. >>> >>> Why does the application need to know about serf_config_t? >>> The serf_config_t baton is passed by the context loop to the request >>> bucket and response bucket. Any bucket in the request/response chains >>> needs to pass this baton to the next bucket, so that the new logging >>> feature works correctly. >>> An application that implements its own buckets has to implement the >>> set_config() method to pass the serf_config_t baton to any wrapped >>> buckets. >>> >>> What are the benefits to the application? >>> First, by giving application buckets access to information stored by >>> serf (host name, port & ip addresses). An application can use this to >>> implements its own logging. >>> Second, by allowing the application to store its own key/value pairs >>> to pass around between buckets. Of course, the application can provide >>> any information to its own buckets by modifying the bucket >>> constructor, a luxury we don't have in serf due to backwards >>> compatibility guarantees. So what's a benefit for serf might not be as >>> useful for applications. >>> >> I understand why application need access to serf_config_t, but I still >> do not see reasons to support storing application data in >> svn_config_t. In opposite I see two arguments to use serf_config_t >> only for serf data: >> 1. No compatibility problems in future >> 2. We can have simple and very efficient store using pre-allocated >> since we know keys count >> > > Fair enough, I don't have good arguments pro this feature. Lieven, sorry for delayed reply.
Could you please update serf_config_t documentation (or code?) before 1.4.0 to avoid API promise? -- Ivan Zhakov