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
[email protected] <mailto:[email protected]> (Work) +1
none currently
AT&T Labs - Research; member of USENIX and LOPSA
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
