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] (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
