On Thursday, March 24, 2011 06:20:52 PM [email protected] wrote: > Hi Carsten, > > > From: [email protected] [mailto:[email protected] > > Sent: 24 March, 2011 09:08 > > Please also remember that if there is supposed to be a technology > > selection, your dispute document also has to list people/companies > > publically committed to the task of implementation/maintenance. Actual > > contribution/commitment weighs harder than numbers sometimes. > > Both solutions have people committed to it. > > > It's pretty obvious Intel has knowledge assets and people doing > > SyncEvolution/EDS already so they would probably not be interested in > > investing in the alternative. Which means someone else has to do the > > lifting. We can't ask for Intel's investment into technologies or > > strong arm them, nor should we. > > True, and at the moment they can't rely on Nokia. But Nokia does not > control tracker either, most of the tracker guys are external consultants. > > > If I was a product manager or TSG looking at the technology > > choice/selection I would look, even before looking at the numbers, > > check if there's actual resources listed that will actually do the > > hard lifting for technology direction and discard the technologies > > that doesn't have sufficient. And then evaluate based on the facts. > > There are two things: > 1. For short term, doing the homework: MeeGo needs to maturize as fast as > possible, and we need to get the releases rolling with usable content. > 2. MeeGo needs to be competitive on the long term, even become the leading > innovation platform of the future. > > Your comment and Intel's decision addressed the first part. > But there is a lot of competition out there, which is pulling away on the > integrated content handling technologies that e.g. tracker tries to cover > (Android by big margin, and I surmise WP7 might have something too), so > there should be a long term technology selection plan, too. Very well put.
We have to be 10x better than the competition otherwise we are going nowhere. In my opinion adding another 'data silo' for contacts in the way switching to using EDS would do, is no better than being 1x the competion although it might be the less risky option in the short term. I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely broken with respect to sharing data between applications. As far as I know, each application is expected to have its own way of storing data and there are obvious real problems with that simplistic way of hiding the Unix file system from users. I don't get the impression that Android is much better. If we are comparing Tracker with EDS we are not comparing like with like. The problem is that we haven't got as far as implementing elegant RAD tools that allow applications to make use of the linked cross-application data in Tracker. Nor have we got as far as making use of the fact that local RDF data can be combined with data stores out on the web. For instance, you may have some music album with metadata stored in Tracker and might like to make a query to web based SPARQL endpoints such as DBpedia for further info. The RDF linked data approach allows ontologies to be linked via mechanisms such as 'SKOS' (in SQL terms I would describe that as a way of making one database schema map onto another). That way we can link local personal Nepomuk data with web based RDF resources, such as FOAF or whatever, that are out on the web of linked data. We are talking revolution here, and certainly Intel might not have the resources to make that happen in-house, but why should that slow down the community based MeeGo project? -- Richard _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
