On Mon, Aug 31, 2015 at 3:14 PM, Ivan Zhakov <i...@visualsvn.com> wrote: > 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?
It's on my TODO list, thanks for the reminder! Lieven > > -- > Ivan Zhakov
