On Friday 09 January 2015 11:14:31 Carsten Haitzler wrote: > > No, that's not what I am saying at all. I was specifically saying that > > Mobile needs *don't* trump IVI needs. I was fearing that "2.3 > > compatibility" would be used as an excuse to break what has been done. > > but you were saying that ivi needs DO trump mobile (for example). that > multiuser as a feature (a requirement for ivi), is reason enough to > break compatibility for 3rd party mobile developers. that an api can be > removed (thus breaking compat) if it were to make ivi multiuser > break/have problems etc.
Yes and no. a) IVI needs to not trump Mobile needs. Similarly, Mobile needs do not trump IVI. They have the same level. b) the new 2.3 API is entirely unreviewed; it's not been looked into by the Tizen devs besides the few who participated in its closed development With (a) alone, we conclude that any new thing coming in for Mobile needs to adapt with what's already there in Tizen 3, without breaking it. It's ok to modify what's there, but it can't break. That would mean Mobile would get a higher priority and that's not the case. With (b) alone, we conclude that the new API needs to be reviewed. It's possible the reviewers may request changes to the API because that makes them better. Since we're all professionals here and do understand the value of compatibility, any requested changes -- if any -- will be only because they are really required, like security issues or future maintenance burden. If you put the two together, that gives IVI a slight edge, for the simple fact that it's already there and it did go through the review process. The new API is the newcomer and the bigger burden falls on what comes later. Where there are conflict, it's the responsibility of the proponents of the later feature to figure out a way. If that requires modifying the API because there's no other solution, so be it. > > In fact, I am saying that multiuser needs of IVI deserves the *exact* same > > respect and attention as the mobile needs. The multiuser support was > > reviewed and discussed before being accepted. Therefore, all other > > changes to Tizen Mobile 3.0 need the same. > > > > So this is simply what Dominique was asking for: visibility of the changes > > so that they can be properly reviewed by anyone interested. > > but that is not what your prior email said. what you say now makes > sense, but it comes with a gotcha. changing apis (removing, modifying > names, arguments or functionality that would break what they are > documented to do that developers rely on), is not something you can just > decide to do arbitrarily because it may break another feature. you did > say it WILL be broken (modified or even removed) if a conflict is found, > and that is making a statement of decision already that compatibility is > irrelevant to you when it comes to tizen development vs goals. Yeah, I wanted to get your attention. That's why it was intentionally vague. Let me repeat again the above: the burden is now on the proponents of this new feature to support what's already in Tizen 3.0 without breaking it, because it's there and has been collectively reviewed. If the proponents can't do it, then the API will suffer. They should have done the collective reviewing before the need for 3rd-party compatibility was set. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
