On 29.07.2014 20:11, Riccardo Padovani wrote: > > On Jul 29, 2014 6:26 PM, "Christian Dywan" > <christian.dy...@canonical.com <mailto:christian.dy...@canonical.com>> > wrote: > > > > Hey everyone, > > [...] > > > - Please point out any benefits and drawbacks you see with either API > > and reply to this thread > > Hey Christian, > Thanks for your mail with all explanations. > I'm on holiday and I had not time yet to see all differences, but I > don't see advantages in Ubuntu.Components implementation, but > disadvantages. > > Could you please point me out on which are advantages to fork a > component that has all features we need? > > I mean, unless upstream drops support to this new feature, IMO we > don't need a fork that creates incompatibility between our app > implementation and standard implementation. > > Regards, > Riccardo > > P.s: reading again the mail I think could seems ironically or rude, > but it's only due my bad English. My mail is really a question: which > could be advantages to have our own implementation? > At the time it wasn't a fork, the Ubuntu implementation came first chronologically speaking. So it's more like, we have it, so we can re-evaluate if it's better or not. The second point you're making is in fact more relevant, the upstream API is currently experimental and unsupported so we have to be comfortable maintaining/ using it even if upstream drops it, which has happend with some components in the past.
So did you check that you can do everything you need with
Qt.labs.settings functionally?
ciao,
Christian
signature.asc
Description: OpenPGP digital signature
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
