[zeromq-dev] Logging format for sys://log transport
ph at imatix.com
Tue Nov 16 08:01:32 CET 2010
Sorry, that should say 'inproc transport'. My spelling checker got in the
On 16 Nov 2010 07:59, "Pieter Hintjens" <ph at imatix.com> wrote:
> A simple idea for selection by severity. If severity is a repeated
> 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:
>> 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.
>> 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
>>> 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
>>> 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
>>> (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
>>>> We can maybe get some inspiration from how linux /proc
>>>> pseudo-filesystem is managed...
>>> 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...
More information about the zeromq-dev