[Xesam] Nepomuk/Xesam future (was Re: condition of 1.0 ?)

Mikkel Kamstrup Erlandsen mikkel.kamstrup at gmail.com
Sun Apr 26 05:41:38 PDT 2009


2009/4/26 Ivan Frade <ivan.frade at gmail.com>:
> Hi
>
>  It looks like the problem is not a change of direction, but what to do with
> the current work. We can release a XESAM 1.0 but:
>
> 1) How many projects are going to implement it?

I don't have exact number heres, as for server implementations I think
Beagle, Strigi, and Pinot might still serve up Xesam interfaces. The
Beagle one is more or less ready (but needs update from 0.95 to 1.0)
and I've talked with Fabrice on doing a joint venture to get Xesam
support in Pinot. Strigi had a fairly complete impl last time I
checked, but I don't know how that is doing these days...

As for clients we have at least a handful early adopters that I've
heard from, just on the G*-side of things. Considering how few people
actually care to report back when they play around with stuff and the
nature of the spec being unstable, I actually think that there is
quite a lot of people out there looking at Xesam 1.0.

> 2) If the change to nepomuk based ontologies and sparQL happens and we call
> it XESAM 2.0... the specs will be _completely_ incompatible.

This is only a problem for those talking to the Xesam provider
directly. Otherwise a lot can be done inside client libraries. It
should be quite doable to implement a Xesam 1.0 proxy on top of the
latest Xesam 2.0 APIs. Then you just need to do on-the-fly ontology
mappings and everything should work...

>  My point is that to release a spec just for the blessing of having a spec
> or because some work was already done doesn't sound right.

That is not the point. The point is that a lot of people can actually
do stuff with the spec *now*, and not in 1-2 years when we have 2.0
ready with client libs and backends.

Another, more important point, is that a lot of people have been
awaiting Xesam 1.0, expecting it already before we wrote 2009. I think
it would be unfair and arrogant to simply let these people down.

>  For the credibility of the project, i think it is as bad to release
> something and dont commit to it as dont release anything.

I can see this problem. We have the choice of two evils here I
believe. And who says that we wont commit to it? I fully intend to
commit to it. If I complete my roadmap for Xesam Glib
(https://blueprints.launchpad.net/xesam-glib) then it will be a breeze
to add Xesam 1.0 support in all sorts of apps (both server and
client).

I think that if we release 1.0 with a note saying that 2.0 will be
completely incompatible and will arrive in 1 year (at the earliest!)
will be the "fair" choice.

-- 
Cheers,
Mikkel


More information about the Xesam mailing list