Sinzui

I brought most of www.gnome.org up to XHTML compliance last weekend. There is some PHP changes to do, but we may just pull PHP from the site all together. The GST and GNOME-Network projects may want to start making plans to switch from PHP to flat HTML.

Last night I was looking at the strange markup the News Summaries on developer.gnome.org. HTML <hr> elements were appearing instead of XHTML <hr /> elements. Unable to locate the source of the phantom elements I went to bed. I awoke 60 minutes later at 12:30 AM with the Monkey God whispering answers in my ear. Beware the Monkey God's code; it is a zen-like language that is often undecipherable the morning after. This morning I had indeed fixed the <hr> problem by changing the xsltproc HTML option to XML plus a few rule refinements, but created wacky empty anchors in the process. The News Summaries were valid, but would not display correctly in the browser. I couldn't figure what I was doing last night, but I was vaguely aware that the Monkey God made no mention in the technical requirements that the pages would actually work.

Thanks to jamesh who provide a patch to fix the problem. No doubt he can decipher the Monkey God's code.

I've been converting the encoding and markup of the GNOME Web sites in an effort to avoid doing some real work. We are moving the GNOME sites to UTF-8 and XHTML to catch up with standards. The Foundation and GUADEC sites are complete. The main portion of www.gnome.org is complete, the PHP portions of the w.g.o and the projects are my next tasks. If you maintain the pages for a project on w.g.o and you don't want me touching your content, send me an email. I'm fixing the developer Web site last because it has the most content, and the content is in a very unpredictable state.

We have a number of ways to generate Web content, some special to the Web, other common like DocBook and gtk-doc. We need to regenerate some of the content as XHTML. Older content that that isn't worth regenerating can be updated by hand, or we can label it as deprecated (or even historical).

Converting the character encoding isn't too difficult, but there are some inconveniences. Source code is stored in CVS in the encoding of the last developer or tool; some code in GNOME CVS is not UTF-8 and will not display right on cvs.g.o. This is a brief sample of invalid UTF-8:

./gnome-vfs/libgnomevfs/gnome-vfs-job-queue.c ./esound/esdplay.c ./libgnome/libgnome/gnome-config.h ./libgnomecanvas/libgnomecanvas/gnome-canvas-text.c ./libbonoboui/samples/compound-doc/container/container-io.h ./libgnomeui/libgnomeui/gnome-scores.c ./gnome-themes/gtk-themes/Mist/src/mist-style.c ./gnome-applets/battstat/acpi-linux.c
./gtkhtml2/libgtkhtml/gtkhtml.h 

There have been accusations of late, implying that Campd has worn a Tutu. We can only image. For those of you with poor imaginations, I offer this:

I've been hacking a lot on metadata with great success. My application does nothing, but it does it very well. Really, I'm very proud I have code structured to work when I put real logic in the methods.

I selected some existing schemas that I think the metadata db should know out of the box: Dublin Core (documents), FOAF (people), EXIF (photos), MusicBrainz (music), IMDB (movie), and a few others. Absent is a schema for the filesystem. I think I'm the only person thinking about metadata as an alternate index to the filesystem. I need to create a schema that represents stat, mime-type, and nautilus thumbnails + emblem/keywords.

PS. I've switched from my usual britpop selection to the darker tones of Placebo, British Sea Power and Interpol. I feel more productive. Don't fall to sleep with Placebo playing in a loop; I woke up feeling like I had spent the evening on a drinking binge.

I've been too busy to make any metadata/search contributions this year, but I'm trying to make time for what is import–a desktop that just works.

As much of the Evolution-Data-Server deals with metadata, would it be wiser to store all metadata in e-d-s? I've always planed to put metadata below gnome-vfs because file and user metadata predates gnome-vfs operations. But my extending e-d-s to contain file file data like Posix, EXIF, ID3, etc., we have one, albeit fractured, source for metadata.

I've long advocated separating search from metadata because there will never be one source. I'm pulling the metadata database out of Medusa because users will want to search Google and p2p shares like iFolder and Gnutella. Moreover, By separating the repository from the querier, I can address some security issues by having public and private native GNOME repositories. The querier translates and dispatches queries to the repositories, then merges the results.

A smart GNOME-metadata-daemon will provide direct metadata access to manager apps like Nautilus and Rhythmbox, and associative tools like bookmarks for Epiphany. Querying and reconciling the contents a folder with 1000s of files will be faster than scanning the disk for each file.

Several strategies are needed to keep the metadata repository current. The g-m-d may use FAM to watch a few folders where change frequently happens, and calls an indexer to extract the metadata when after each file update. the g-m-d will launch an incremental indexer to crawl personal folders from time to time to update the repository. the g-m-d will examine the changes to update the set of watched directories. GNOME-VFS may be aware of the g-m-d and will use an introspection library to extract metadata during writes.

The GNOME-metadata-daemon is really a mess on my harddrive. Adding this kind of code to the dependency list is a bit tricky.

                         Indexer                             |       libintrospection (metadata extraction + creation)                             |                GNOME-VFS (virtual filesystem)                             |    GNOME-metadata-daemon (controls access to the repository)                             |       libmetadata (RDF obfuscation + schema management)                             |                librdf (metadata repository) 

libintrospection would normally exist on top of GNOME-VFS. To catch the data being written by a GNOME app, libintrospection would either be below GNOME-VFS, or is a part of GNOME-VFS. libintrospection would be similar to GStreamer pipelines. Pipelines of introspectors would be called to extract and create metadata. As mime-type is an aspect of metadata, the pipeline manager must construction the pipeline as data is extracted. After each step, the pipeline manager must determine which introspector to call next to complete the gathering of metadata. Introspectors would be registered in GConf like thumbnailers, so new introspectors can be added by applications.