[zeromq-dev] Logging format for sys://log transport
sustrik at 250bpm.com
Tue Nov 16 00:04:11 CET 2010
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 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
> (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
>> 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