Comprehensive logging and log transmission

[Sander van Grieken]

> Logging library
> ---------------
>
> I think I want to use SQLITE 3 as the underlying storage for the
> events. It's a smallish library with no external dependencies and
> handles concurrency issues decently. Other options would be atleast
> Berkeley DB and HDF. I'm trying to avoid anything that would affect
> the event-loop of the program or require socket communications.
>
> Logging an event would be really straightforward. Just open the
> database, insert one row with timestamp and data, and be done with it.
>
> I will probably use a Python implementation initially, until the
> features have stabilized somewhat.

What's wrong with plain old syslog?

> Event format
> ------------
>
> Well, obviously the event needs a timestamp. In addition to that, I
> think it would be good to enumerate the events with an id number. I'd
> rather not trust timestamps for any functionality since a clock can be
> wrong.

Well, for most uses relative time (between events) is more important than
absolute time.

> Then the event needs to actually carry the message - but the format
> there is still an open issue. There most likely needs to be a message
> type in some form, but should the body be typed? A single string? Byte
> array? Key/value mapping? I don't know yet. What I do know is that I'd

Why restrict yourself here? if the process name gets dumped in the log
(which syslog usually does) you already know how the logging events are
formatted and you can extract all the information your want.

Besides, syslog has classification and severity markers, so you already
have basic filtering capabilities on the device, e.g. sending some logging
data ASAP over GPRS, and some logging data when a fatter connection is
available.

I think you're trying to reinvent the wheel here :)

grtz,
Sander