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

[Pieter Hintjens]

OK, /me found a real keyboard and can explain this better.

Here's my proposal for the topic header:

* Number of repeated characters indicates severity from 1 to 3 (X =
information, XX = warning, XXX = error)
* Character indicates category of error: '?' indicates internal 0MQ
error, '*' indicates bad data, '#' indicates resource error, etc.

Now I can subscribe to keys like '?' (any internal error), '***' (only
serious bad data errors and up), '##' (any resource errors apart from
informative).  It is trivial to turn XXX into 3 if that's needed.

This is just a sketch, we may want more severity levels eventually.
I'd probably not use version numbers in the API since it would be very
hard to manage multiple versions of the error subsystem at once.

And we don't need multipart data, that is too complex.  Just a topic
that specifies the severity and category, and then a textual message,
IMO.  The simpler the better at this point.

-Pieter

On Tue, Nov 16, 2010 at 7:59 AM, Pieter Hintjens <ph at imatix.com> wrote:
> 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
>>>
>>>
>>>
>>>
>>
>