serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <i...@visualsvn.com>
Subject Re: [serf-dev] Plan to release serf 1.4.0 (+ TODO list)
Date Mon, 31 Aug 2015 13:14:45 GMT
On 8 September 2014 at 13:03, Lieven Govaerts <lgo@mobsol.be> wrote:
> On Mon, Sep 8, 2014 at 11:57 AM, Ivan Zhakov <ivan@visualsvn.com> wrote:
>> On 7 September 2014 12:32, Lieven Govaerts <lgo@mobsol.be> wrote:
>>> On Mon, Sep 1, 2014 at 7:08 PM, Ivan Zhakov <ivan@visualsvn.com> wrote:
>>>> On 19 August 2014 12:39, Lieven Govaerts <lgo@mobsol.be> wrote:
>>>>> On Thu, Jun 26, 2014 at 1:14 PM, Ivan Zhakov <ivan@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

Mime
View raw message