Sorry, that should say 'inproc transport'. My spelling checker got in the way. Android.... On 16 Nov 2010 07:59, "Pieter Hintjens" <[email protected]> wrote: > A simple idea for selection by severity. If severity is a repeated character > 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. > > -Pieter > On 16 Nov 2010 00:04, "Martin Sustrik" <[email protected]> wrote: >> 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
