2009/4/26 Ivan Frade <[email protected]>: > 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 _______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
