[Telepathy] thinking about a new log format for telepathy-logger

[Cosimo Alfarano]

On Tue, 2010-03-16 at 14:33 +0100, Senko Rasic wrote: 
> > A logger doesn't need to push loads of data at the same time. But it
> > might need instead to rollback. Currently we don't need it, though.
> 
> Hm, in which cases (besides error-while-logging?) would a rollback be 
> needed?

None. Usually the pattern is "send and forget". Each store will handle
the message independently.

My point was just hypothetical, if TPL needed transactional writings, it
would be to be able to roll the data back.

It would be interesting for a logstore to be able to roll back its
operations on message M, if another logstore fails in processing M.
Interesting but not strictly necessary, IMHO.

Also on errors, currently we do atomic writings (usually a single
updated/insert per message) even without transactions.

Different logstores work independently, so no real need of rolling back
if "the next" storing operation fails.

I'd try to keep it simple and limit any use but the basic
storing/querying. The safe way.
It's always possible to enhance TPL use of SQLite when things work :)

> Time/message count based transactioning might make sense. E.g. don't log
> more than once a second, or more than once in 5 seconds unless more than 
> 100 messages are queued. But in this case, there's an issue of lag 

Well, on this scenario, what I said (a logger doesn't need to push loads
of data at the same time) fails :)

In a embedded device scenario, though, joining a high traffic chatroom
would be rare and probably some sort of advice to turn off logging for
the account would be interesting.

In the case of 100+ enqueued messages, a transactional INSERT would be
helpful.
I suppose fdatasync() called just once instead of N, reducing syncing
time notably.

C.