December 31st, 2004

  • evan


I guess those of you who don't follow LJ stuff as closely probably haven't seen ljArchive [Windows-only], which does all sorts of amusing analyses of journal data. Before I had even seen that I had imagined LogJam eventually doing those sorts of things, and I'm happy to see others have actually made it happen. Software is definitely moving to an online-based world and it's worth some consideration to see which features could be done by LJ and which are processing-intensive enough to require client-side code. (In some sense, any sort of report could be done as a batch job server-side, I guess...) For example, the author of ljArchive proposed that a fancy client could assist with jwzrants-style cross-linking between entries.

Over the Christmas break I did a bit of LogJam hacking to make it export to sqlite directly. I had been hacking all of this O'Caml code -- I have a simple sqlite3 bnding, and then HTTP libraries -- with the sorta eventual goal of getting a useful export of my LJ data, and then it occurred to me that LogJam already has done all of the pain of LJ exporting. Of course, doing that goes back to mucking with autoconf to conditionally depend on sqlite, etc. and it sorta tempts me to gnaw my arm off to escape. I'm also envious of the HTML, graphing, etc. widgets that .NET on Windows likely provides. Every time I have to manually construct in C what's effectively a closure I get all frustrated.

I've been especially tempted to make a good journal search. Now that I work at a Search Company it's funny that I used the term "search" for the LogJam journal-scanning functions, which actually just iterate over every entry. I haven't looked at any search-related code at work yet and I only have a vague impression of how it works -- y'know, the indexing process generates posting lists and then you intersect them to do boolean ANDs -- and I thought that'd be a fun project. But maybe it's too close to what I actually do work on (scoring, roughly) to be kosher.