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
