On Jun 26, 2006, at 3:59 PM, Ashkan Soltani wrote:
Hey all
I'm Ashkan, one of the interns working with the PPD team this
summer. My project it to instrument a usage tracking compoment
within Chandler in an attemt to better understand how dogfooders
are using the app. The idea is if we can gather logging data, we
can make better assumptions of what people actually do on a regular
basis and focus energies in improving those activities.
With a lot of JohnA's help, I've managed to put together a small
compement that logs blockEvent and some of context to a file or
stderr. (I should preface this by saying that I don't have any
previous exp w/ Python .... most of my development was in Perl and C)
Now that I'm able to log the events, I need to find a way to
consolidate this logging information and get it back to us for
review/analysis (both automated statistics crunching as well as
individual workflow analysis)
The 'logging' workflow is:
- dogfooders enable 'logging' via a pulldown in the Chandler test
menu pulldown
- they enter are prompted for a 'username' (basically an arbitrary
identifier), displayed some privacy disclaimer, and then a unique
userid is generated for them (or possibly pulled from a system
variable if it exists?)
- the system logs user data, either on the local filesystem or
some remote logserver
- if the logging is local, then on some interval, chandler would
'send' this information to us somehow
- users can disable/re-enable logging at any time
Questions:
What would be the best way to 'collect' this data, given that users
may or may not have network access, or could possibly be
firewalled, etc. (*caveat: i'm looking for a quick low-hanging
fruit such that more time can be spent on the analysis side of the
project)
Possible idea's I've considered is using HTTP in real time (or via
implementing a buffering system) to log the data to a central
server. There's some direct support for this in the python logging
module under HTTPHandler: http://docs.python.org/lib/module-
logging.html
I think that some kind of HTTP based solution is the way to go.
Alternatives would be to use a 'sync' procedure, either via rsync/
ftp or perhaps even the background sync module to upload the
logdata to our servers. The implementation for this stuff would be
a bit more involved, specially since I'm not storing the logdata in
the repository and would need to figure out how to encapsulate it,
but it might be more compatible with the rest of the chandler
methodology.
I think you are going to end up with firewalling problems here if you
use a protocol other than http, or something that can't tunnel over
http. Actually, I think that in some version of the future, storing
these traces in the repository might be interesting
The last/simplest approach would be to use simple SMTP to post the
information since we know that more often than not, users will have
'at least' SMTP access from within Chandler since it is a mail app
after all.
I don't know that you can count on people having set all the SMTP
settings. I am dogfooding the calendar, but I do not have the SMTP
or IMAP settings configured.
Another application for your instrumentation machinery is to build an
Attention Recorder <http://www.attentiontrust.org/services> for
Chandler. While this is probably out of scope for Beta / 1.0, this
is something that I am personally very interested in investigating /
experimenting with. Is your stuff checked in somewhere?
Ted
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
