• 2004
  • September
  • 07
  • Cinemon gets code back from common applications... (Or, my day in slogging...)

Cinemon gets code back from common applications... (Or, my day in slogging...)
Written by on in Snaking.


I've been working on other projects for a couple of weeks now, ripping pieces of Cinemon's application framework out and using them for the other projects as I go. Today I took my "day off" to try to move Cinemon forward.

Most of the day was spent working on the hierarchy-importer. That moved forward quite a distance, but I got bogged down on the question of whether to try to unify objects that aren't explicitly matched, delete the old versions indiscriminately, just leave them, or what. Still haven't figured out what's best. May have to do some after-work hacking this week.

So toward the end of the day I decided to see if I could get Cinemon using the common application framework.

"Why?" No-one asks, since this is stultifyingly boring to everyone save Tim, I'm sure.

Well, to reduce duplication, certainly, but more because in the last few weeks I've done a lot of work on that common code, and most importantly, I switched to using the standard logging module instead of the database-based one, I figure that will likely make Cinemon significantly faster all by itself.

Still need to do a lot of testing, particularly for the Zope-hosted UI to make sure it's working properly, but the Twisted-based scanner code seems to be working fine with the back-ported code.

Comments

  1. x

    x on 09/07/2004 7:57 p.m. #


    Hmm, i've been actually today looking at old cinemon logging code to see what you were doing with it... with an eye of converting it for media corp use... <br />
    <br />
    I can certainly see it being a slowdown when you're logging such masses of info as you are... there needs to be a combo maybe... <br />
    <br />
    The database based logging is so incredibly useful in the billing system. Hard to imagine life before it. It becomes almost more of a management tool than a debugging/admin tool sometimes. It shows admins who's doing what very easily via the web. And when trouble does strike, the search interface makes things so much easier than parsing logs for the info you want... <br />
    <br />
    However for database logging I'd not be logging every robots.txt download (except perhaps under debugging circumstances of course)... id most likely log just the beginning of most processes and the end (or just the end, if it's something like a user activity). The first log entry with some description of what is to be done (ie counts of records, whatever parameters), and then at the end a summary of what was done... along with of course any notable problems along the way.<br />
    <br />
    <br />
    <br />

Comments are closed.

Pingbacks

Pingbacks are closed.