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

[Martin Sustrik]

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/3bc92ff5/attachment.htm>