tever semantics amc had in mind? I’m not too concerned about changing the
functors return values here, and we could also come up with a new naming scheme
for all such APIs (and deprecate the old one).
If we go the route of making a new version of TSMimeHdrFieldNext() we should
consider TSMimeHdrFie
>>>
>>> 在 2014年8月16日 星期六，上午4:55，James Peach 写道：
>>>
>>>> On Aug 15, 2014, at 10:23 AM, Alan M. Carroll
>>>> mailto:a...@network-geographics.com)> wrote:
>>>>
>>>>> This came up yesterday on the IRC. The problem is
8月16日 星期六，上午4:55，James Peach 写道：
> >
> > > On Aug 15, 2014, at 10:23 AM, Alan M. Carroll
> > > mailto:a...@network-geographics.com)>
> > > wrote:
> > >
> > > > This came up yesterday on the IRC. The problem is that every call to
> >
On Aug 16, 2014, at 8:29 AM, Brian Geffon wrote:
> I'm definitely +1 for functor/iterator semantics, ideally it could be done
> in such a way as to preserve backwards compatability.
My initial reaction is against a callback-based API because that's not
consistent with the existing API patterns.
I think there are two reasonable approaches -
1) Iterator style. In this case we either create a new iterator type or re-use
the FieldHandle as an iterator. In this case you get a handle to the first
field, and then re-use it for each field. This saves the expense of allocating
a new handle for
On Aug 15, 2014, at 3:13 PM, Nick Kew wrote:
>
> On 15 Aug 2014, at 21:55, James Peach wrote:
>
>> What's a real use case for iterating over all the headers?
>
> Ironbee. Or any WAF, or WAF framework.
ah, waf and header whitelisting makes sense
>
> Or performance analysis tools.
>
> --
>
gt; (mailto:a...@network-geographics.com)> wrote:
>>
>>> This came up yesterday on the IRC. The problem is that every call to
>>> TSMimeHdrFieldNext allocates a MIME field handle which gets very slow if
>>> you use the function heavily. One suggested approach was to s
.
--
portl4t...@gmail.com
在 2014年8月16日 星期六，上午4:55，James Peach 写道：
> On Aug 15, 2014, at 10:23 AM, Alan M. Carroll (mailto:a...@network-geographics.com)> wrote:
>
> > This came up yesterday on the IRC. The problem is that every call to
> > TSMimeHdrFieldNext allocate
I'm definitely +1 for functor/iterator semantics, ideally it could be done
in such a way as to preserve backwards compatability.
On Aug 16, 2014 10:35 PM, "Leif Hedstrom" wrote:
> I have some mixed feeling on this. Such as, is us TSMimeHdrFieldGet a
> better candidate to improve for looping over
I have some mixed feeling on this. Such as, is us TSMimeHdrFieldGet a better
candidate to improve for looping over all fields ? Or even a new API with
functor semantics?
TSMimeHdrFieldGet at least avoids one loop to avoid finding the slotnum
> On Aug 16, 2014, at 5:29 AM, Brian Geffon wrote:
>
If no one has already started on a fix I can take this.
Brian
On Aug 16, 2014 6:13 AM, "Nick Kew" wrote:
>
> On 15 Aug 2014, at 21:55, James Peach wrote:
>
> > What's a real use case for iterating over all the headers?
>
> Ironbee. Or any WAF, or WAF framework.
>
> Or performance analysis tools
On 15 Aug 2014, at 21:55, James Peach wrote:
> What's a real use case for iterating over all the headers?
Ironbee. Or any WAF, or WAF framework.
Or performance analysis tools.
--
Nick Kew
don¹t support lower case headers and require each header to be
converted to camel case.
Thanks,
Sudheer
On 8/15/14, 1:55 PM, "James Peach" wrote:
>On Aug 15, 2014, at 10:23 AM, Alan M. Carroll
> wrote:
>
>> This came up yesterday on the IRC. The problem is that every cal
On Aug 15, 2014, at 10:23 AM, Alan M. Carroll
wrote:
> This came up yesterday on the IRC. The problem is that every call to
> TSMimeHdrFieldNext allocates a MIME field handle which gets very slow if you
> use the function heavily. One suggested approach was to switch the allocator
Leif,
> But if the goal is to always iterate over all headers, I’m guessing (but not
> sure?) that it could be done more efficiently with an API that assumes so ?
> But alas, I don’t know what the use case here is, I’ve yet to see one where
> iterating over all headers is required (you usually
On Aug 15, 2014, at 12:33 PM, Alan M. Carroll
wrote:
> Leif,
>
>> Is the goal here to iterate over all headers? If so, maybe some sort of
>> iterator functionality would be more appropriate, similar to how we added
>> the iterator (with a callback) for lib records (i.e. TSRecordDump() )? Can
On Aug 15, 2014, at 12:33 PM, Alan M. Carroll
wrote:
> Leif,
>
>> Is the goal here to iterate over all headers? If so, maybe some sort of
>> iterator functionality would be more appropriate, similar to how we added
>> the iterator (with a callback) for lib records (i.e. TSRecordDump() )? Can
Leif,
> Is the goal here to iterate over all headers? If so, maybe some sort of
> iterator functionality would be more appropriate, similar to how we added the
> iterator (with a callback) for lib records (i.e. TSRecordDump() )? Can that
> help simplifying / improve such operations?
If you add
On Aug 15, 2014, at 11:23 AM, Alan M. Carroll
wrote:
> This came up yesterday on the IRC. The problem is that every call to
> TSMimeHdrFieldNext allocates a MIME field handle which gets very slow if you
> use the function heavily. One suggested approach was to switch the allocator
This came up yesterday on the IRC. The problem is that every call to
TSMimeHdrFieldNext allocates a MIME field handle which gets very slow if you
use the function heavily. One suggested approach was to switch the allocator
from a global to a per thread.
I think it might be better to add
20 matches
Mail list logo
