beep is designed in such a way that you basically pay for
what you use. if you know before hand that you're going to
have at most two channels open (channel zero for management,
and another channel for data exchange), then you can write
the transport mapping stuff in one screen of C (maybe
Rainer,
I had a similar reaction when I first looked at RFC3195 and BEEP etc, with a
view to implementing it. However, I don't think it is as complex as it
appears at first glance. It also seems to me that any of the overhead is
actually stuff that you would be doomed to reinvent in any
well, as the resident beep guy, i guess i get to comment. however,
rather than answer your questions directly, i'm going to state a general
principle and then let you apply it to your situation.
the principle is this:
there is nothing stopping anyone from writing their own limited beep
possibility to specify a kind of simple reliable syslog protocol.
I second the idea of a new simple reliable protocol. It needs to be very
easily implemented, flexible, easy to parse and check for accuracy and
use standard off the shelf components. Mostly, it needs to be simple
if we ever
As I have written the original message, I feel I should post a quick
reply to clarify...
As responsible for the RoadRunner software project I'm
curious as to exactly how you find the library hard to use
for closed-source projects. I'm quite
confident there's a misunderstanding regarding the
BEEP may or may not pay its freight, but I don't see it becoming
available across the board --- including innumerable embedded gizmos
and weird proprietary OSes --- any time soon.
On the other hand, if we started with syslog-as-it-is-today, added
TCP transport, took off the line length limits,
Rainer Gerhards [EMAIL PROTECTED] writes:
Roadrunner (which is hard to use without redisigning your whole application
[and also hard to use for closed-source projects]).
As responsible for the RoadRunner software project I'm curious as to exactly
how you find the library hard to use for
On the other hand, if we started with syslog-as-it-is-today,
added TCP transport, took off the line length limits,
delimited records in the TCP stream with newline, and
permitted (as an option) ISO 8601 / RFC 3339 timestamps[1]
instead of the ambiguous and hard-to-sort ones currently
As for having to re-do auth, privacy, etc., it seems odd not to just
standardize a TCP service and use SSL if encryption/authentication
is desired. Especially since, in the huge-horking-central-logserver
scenario, SSL would let you use commodity SSL accellerators to buy
the needed
2002-12-17-13:42:38 Marshall Rose:
Bennett Todd:
[ use SSL for auth and encryption ]
and this works great, right until someone decides they have a requirement for a
security technology not met by ssl, at which point it's fatal.
Well, it's fatal, or else it's not.
If an additional function,
in fact, the just say no thing works great for most of
beep's features. what you're left with is a mandatory framing
mechanism and some xml parsing for channel 0.
Well, I thought this was not the spirit of BEEP - but I guess you must
know better ;) I'll re-read the RFC in this regard.
The BEEP protocol looks like it has all the right features (and then
some!). But as Marshall pointed out, the syslog over BEEP doesn't
need all the flexibility and power of every single BEEP feature.
From our standpoint, the problem has never been BEEP, its the
complicated and oftimes buggy (or
Hi,
I appreciate the thoughts of everyone on the topics brought up so far.
Let's make sure that we all understand what we can do within the current
scope of the WG.
TIMESTAMP This field may be changed in syslog-sign. We'll have to rev
3195 to accept this after syslog-sign is
13 matches
Mail list logo
