[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.

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
>>>> by the bind address. in fact, we could use this to distinguish
>>>> for example, the first format could be "sys:/log0", and the next
>>>> 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