[zeromq-dev] Logging format for sys://log transport

Pieter Hintjens ph at imatix.com
Tue Nov 16 07:59:57 CET 2010


A simple idea for selection by severity. If severity is a repeated character
string rather than a single byte, you can subscribe to any required level
and higher. Eg. * or ** or *** etc. Since it's an intro transport there is
no real cost. You can use different characters for different categories.
Thus the topic header encodes both severity and category or message.

-Pieter
On 16 Nov 2010 00:04, "Martin Sustrik" <sustrik at 250bpm.com> wrote:
> Oh,
>
> One thing I haven't mentioned: With two distinct endpoints there's no
> strict message ordering. The ordering exists only in the scope of a
> single endpoint. In other words, each endpoint defines it's own message
> stream, completely orthogonal to any other message stream. That, I
> think, is a good clue for determining what should be implemented as a
> separate endpoint and what should not.
>
> Martin
>
> On 11/15/2010 11:40 PM, Andrew Hume wrote:
>> maybe, although it is a different beast.
>> (fwiw, i was part of teh original plan 9 team that invented that stuff.)
>> there are two main lessons here:
>> 1) have the file hierarchy statically/dynamically track the underlying
>> semantics
>> 2) use byte streams for all communication
>>
>> for example, the consequence of 1) is that you should/could manage
>> different versions
>> of teh API is by offering all of them simultaneously:
>> bind to "sys:/log/v0"
>> bind to "sys:/log/v1"
>> would give you access to both logging APIs. if you offer both, then older
>> applications need never change if they don't need the new semantics.
>>
>> a consequence of 2) is that all fields are strings, e.g. the format
>> might be
>> pri_string\0type\0message\0
>> (note that in Plan 9, there is no errno, all you could get was teh
>> string version.)
>>
>> On Nov 15, 2010, at 2:04 PM, Martin Sustrik wrote:
>>
>>> On 11/15/2010 09:57 PM, Andrew Hume wrote:
>>>
>>>> i agree with martin; differentiate between logging and performance
stuff
>>>> by the bind address. in fact, we could use this to distinguish
versions;
>>>> for example, the first format could be "sys:/log0", and the next
version
>>>> can be "sys:/log1" and so on. this way we won't need to manage
>>>> migration.
>>>
>>> We can maybe get some inspiration from how linux /proc
>>> pseudo-filesystem is managed...
>>>
>>> Martin
>>
>> ------------------
>> Andrew Hume (best -> Telework) +1 623-551-2845
>> andrew at research.att.com <mailto:andrew at research.att.com> (Work) +1
>> none currently
>> AT&T Labs - Research; member of USENIX and LOPSA
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101116/e0df02dd/attachment-0001.htm>


More information about the zeromq-dev mailing list