unless you think you need something quite different,
just follow existing practice, e.g. syslog.
that is, a type (== facility) and an impact (==severity==priority).
so i would lay it out as
byte 0 == impact
byte 1 == type
remaining bytes are UTF-8 encoding of message.
don't use multi-part (i suspect most people don't handle multi-part);
it seems way overkill.
i bet for most folks, filtering on impact would be sufficient to weed
out most stuff
and the rest can be done manually (no need to invoke complicated
filtering stuff here).
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.
keep it simple until we see a distinct need for something more
complicated.
andrew
On Nov 15, 2010, at 1:30 PM, Mikko Koppanen wrote:
Hello,
short background (and correct me if something is wrong here):
The sys://log transport is an internal transport, a PUB socket
providing logging information on what happens inside 0MQ. The
information has not yet been defined but probably contains things such
as severity, event type and message associated with the event.
The question is how structure this information in the most effective
way? One way would be to use severity as the topic and allow user to
subscribe to all events above let's say level warning but this still
leaves the question about the data format inside the message. My
current thinking leans on something like:
struct zmq_event_t {
uint8_t severity;
uint16_t type;
char *message;
};
where type could be something like ZMQ_EVENT_CONNECT,
ZMQ_EVENT_DISCONNECT, ZMQ_EVENT_HWM_REACHED and so on.
However this probably doesn't include all possible use-cases so it
would be nice to hear ideas on what would be the best way to organise
this information.
--
Mikko Koppanen
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
------------------
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
