RDF work and backwards compat

Vladimir Vukicevic vladimir at pobox.com
Tue, 1 Nov 2005 11:49:37 -0800

On 11/1/05, Axel Hecht <axel@pike.org> wrote:
> If you take a look at http://wiki.mozilla.org/Annotations,
> nsIVariant getAnnotation(in nsIURI aURI, in wstring aName);
> with a namespaced string for the name is just RDF. We may not call it
> that way, but that doesn't change what it is.
> (http://wiki.mozilla.org/Bookmarks_Data_API is even more involved, I
> tried to understand it, I should try again.)

I don't think I agree with that; there is a pretty big difference
between an RDF API and the intent of the annotation service.  At the
simplest level, you can treat both as key-attribute-value triples. 
However, once you start getting into complex values (especially
arrays/sets/etc.), RDF starts requiring lots of hoops to keep the data
representation "RDF".  This could probably be solved with extra
helpings of API niceness, but I'm not sure it can ever get to a point
where manipulating the data feels natural.  (Note: I don't really care
about C++ callers too much in this -- they're going to have pain no
matter what we do.)  If you're just looking at simple triples, I'm not
sure that RDF gets you anything over a simple service tailored for it,

> If we have a problem with our API being taylored to our internal
> datastructure (as the current RDF API is, and as the new proposed API is
> to a similar extent), then maybe it's a better idea to actually make a
> bold statement on what a database-backed storage could provide, which of
> that we wanted to use and then design an API around that, without
> porting the current mozilla/rdf to that.

The database backed storage is just a place where we can store and
access large amounts of data, especially without having to keep the
entire data set in memory.  Some of the APIs built on top of it may
not exploit any of the richer queries possible; on the flip side, some
of the APIs (like history) can and will do so, especially for things
like date range and site queries.  I'll admit I haven't looked
recently at the latest new RDF APIs, though.

> I'm not arguing that RDF is the cow that can shit golden bullets, but
> from our UI, we're moving in that direction, I just wonder why giving
> the cow a new name.

Well, it's more like we're inventing special-purpose cows that can
produce just the right color of bullets instead of saying that gold
works for everyone ;)

> Mentioning Aurora, does anyone remember (or remembers someone who may
> know) why Aurora didn't succeed? It may be nice to incorporate that
> experience into our design discussions.

I'd be interested to know this as well.. from the description on the
web page it sounds like it was just back burnered and then never
revisited, though that may what actually happened..

As for backwards compatability, I'd say don't bother: the components
that are heavy RDF users currently are being rewritten (they'd be
rewritten anyway with a newer RDF API, even if they stayed RDF), and
we never really exposed RDF to content.  It makes more sense to start
RDF support again with a clean slate, instead of having a bunch of
unused legacy baggage hanging off it.

     - Vlad