Neil's Place

April 24, 2003

12:56 AM RDF Stores

Anyone know of a good RDF storage system? I mean a file format that stores RDF data like a database. I'm thinking a Mozilla component could be written that could read and write it.

I ask as applications that use a lot of RDF could get quite large using serialized RDF files. Take a look at localstore.rdf -- it contains a lot of repeated text. That file could get quite large with lots of data in it.

Comments ( 31 )


12:52 AM Aaaarrrrgggghhhh!!!!

Just when I felt like I was starting to make some real progress, I get stopped spending 8 hours hunting down the cause of one bug in some code.

Some good news though is that I think I understand how to deal with the native side of XPCOM and the Mozilla string classes now.

Comments ( 1 )

April 19, 2003

2:00 AM War Poll Results

So it seems that approximately half of people think that after Iraq, the US should turn their focus on attacking and liberating Flint, Michigan.

Fortunately, Flint shouldn't put up much of a fight, so there should be a minimum of casualties. And unlike Iraqi cities, Flint has also conveniently been pre-looted.

Other countries got about 10%-15% of the votes each, except for Iran which got none. That means that an infinitely larger number of people wanted to have the US attack France rather than Iran.

Comments ( 27 )

April 15, 2003

12:18 PM Next development steps

I mentioned that I was working on an RPath language, which is an XPath-like language for referring to RDF data. At first, I had implemented a very primitive version in JavaScript. Now, I've been re-implementing a better version in C++. My first goal is to create a function that will take an RPath expression and return a set of RDF resources that match it. Then, I might even be so bold as to hack the XUL template system in Mozilla to support it.

I'm not sure if adding features to XUL would be a good approach right now though. There are some existing things that need to work better, and if I was going to do development, I might be better spending time working on those. Some common wishlist items people have: editable trees, arbitrary content trees, less crashy listboxes, XUL in XML documents.

Or perhaps people would rather I just continue to work on documentation?

Comments ( 11 )

April 11, 2003

10:51 PM War Poll

Where do you think the US should target next?

Iran
Syria
North Korea
France
Canada
Flint, Michigan

Results

Comments ( 41 )

April 10, 2003

12:11 PM Secret of Programming

I have discovered the secret of how to make writing code more interesting -- make sure that your editor is using a nice font.

A year ago when I was doing something on a Mac (OS X), I wondered why it seemed better working on that platform than others. I thought maybe there was something special about the Mac, or its keyboard, or the Aqua UI. Nope. It was the font.

Now that I've switched fonts on my Linux machine, I'm happier.

Comments ( 35 )

April 7, 2003

10:01 PM Attention web developers

Web developers should read this: Using Mozilla in testing and debugging web sites

Comments ( 0 )

April 6, 2003

11:59 PM On Implementing Features

One thing about creating new features for a product such a browser is the features they are almost always designed and implemented in such a way that is convenient for the creator of a product but not for anyone else (this isn't intentionally done though). The proprietary features of browsers are designed to fit the architecture of the browser so that they can implemented as quickly and easily as possible. They don't go through months of years of iteration like standards do.

If you look closely at some of the documentation of CSS or scripting features of browsers, you will find numerous design decisions that seem odd. This is not because the designers were stupid, but because architectural issues prevented the designers from creating something more sensible.

The IE documentation refers to numerous things that really seem to be only there because some part of its architecture requires it. No other browser would have a need for such features. IE's way of displaying unstyled XML as a 'fancy tree' was fine for it, but since Mozilla can render styled XML directly, that feature took some time to work out how best to implement it, without breaking XML that was supposed to be displayed styled.

Some people have complained that with XBL, one has to add various tags to describe properties and methods, rather than just using a script file with functions in it. While that may seem easier for the XBL author, there may be implementation details that make it harder to handle. What I mean is that given a specific browser architecture, it's possible that a separate script would be difficult for the browser implementor to deal with.

A good example would be the innerHTML property of elements. While this may seem like a convenient way to change the content, it adds a dependency of an HTML parser to the DOM module. And not only an HTML parser, but one that can parse a fragment, not just a document. While this may not seem like such a concern for a browser, it today's world of componentized systems, there may be a product which has licensed a pre-built HTML or XML parser, or may be using a standard parsing library. Since many languages often include an HTML or XML parsing module, developers would tend to just use that. Since the developer doesn't necessarily have the option of changing the parser, if it doesn't provide any hook to handle the innerHTML property, it really isn't possible to include such as feature.

So, don't assume that a feature found in one product is necessarily implementable in another. The standards go through several iterations with comments from many people or groups, in order to ensure that they are the most implementable in the most cases. Propreitary features don't.

Comments ( 25 )