[Chandler-dev] An idea about logging how well Chandler is working for you

[Markku Mielityinen]

Hi,

While working on the feeds parcel, I became aware of a technique that 
some OSAF employees know as a "Morgen trick", which is used in 
osaf/sharing. In this technique, a calender collection is used as a 
logger that monitors repository synchronization. The benefit of this 
approach is that Chandler can be used as a high quality browser to study 
the logged data (as the log is really a calender). I think that this 
idea has not been utilized to its full potential and deserves to be 
discussed in this forum. It seems that this design could be used in many 
places, for example in feeds. But why settle for having such a calender 
collection for each parcel separately as we could have one global 
calender collection, hereafter referred as log calender, for this 
purpose that can be used everywhere in Chandler. To make this even 
better we should be able to make queries to the log calender, which I 
have understood is supported by the repository. I use SQL to illustrate 
the idea whereas Chandler repository specific implementation would of 
course be needed to make it work:

SELECT * FROM logcalender WHERE reporter = 'feedsparcel' AND timestamp 
BETWEEN ... and show this as a calender

Open questions:
* We do not want to bloat repository with unnecessary large amounts of 
data so a consideration is needed to choose what to put in.
* The proposed log calender cannot, nor should it, replace the loggers 
that are currently in place. Again consideration is needed to choose 
what to put in as there is no point in storing too much information in 
two or more locations.
* Is such a calender logger technically feasible?
* Are there others who would like to use such a service given that it 
were available?
* etc...

My original idea is that the log calender would contain information that 
is useful for the end users but not beyond that, i.e. that are aimed for 
developers for bug tracking purposes (of course it could contain those 
as well). This is just an idea and far from being ready for 
implementation so feel free to comment and suggest improvements.

Cheers,
    Markku