serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lieven Govaerts <...@mobsol.be>
Subject Re: [serf-dev] Plan to release serf 1.4.0 (+ TODO list)
Date Wed, 02 Sep 2015 07:35:51 GMT
On Mon, Aug 31, 2015 at 3:14 PM, Ivan Zhakov <ivan@visualsvn.com> wrote:
> 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?

It's on my TODO list, thanks for the reminder!
Lieven

>
> --
> Ivan Zhakov

Mime
View raw message