On Fri, 08 May 2015 20:37:28 +0200 Rafał Krypa <[email protected]> said:
> On 2015-05-06 09:57, Carsten Haitzler wrote: > > i kind of think that it's not worth chasing. 1 app == 1 package. that is > > all upgraded/installed/uninstalled together. it CAN indstall multiple > > binaries (multiple executables and thus icons to launch - this one package. > > it could also installl just data files or shared libs or something else > > with no binaries at all). > > > > as long as: > > > > 1. apps can be installed in $HOME as a user id by that user id with no > > special root permissions we're fine. > > 2. apps live entirely within their directory - any symlinks to data outside > > an app dir is managed by tools outside of the app itself (catch - i might > > point at freedesktop.org for where to put cache and config files like > > ~/.cache and ~/.config - but a bit late for that now - i'd also have just > > suggested we have .desktop files... but anyway - ignore this). > > 3. app install dirs can be moved anywhere in the filesystem and the app > > must continue to work (if launched again there). > > > > i think this should be sufficient. for now at least. hybrid aps will just > > have to update both ends at the same time. > > This isn't that simple. > I'm trying to support hybrid apps constructed from two parts from different > application frameworks. Like in the old Tizen2.x, where hybrid apps were > formed by WRT and OSP parts.Those parts were installed separately, by two > dedicated installers that didn't know about each other. imho that just is not worth supporting. a hybrid app is a unit. the front end is tied to the back end (web to native). they should be installed, upgraded and removed together as a unit. > My understanding of the whole concept of pkgId and appId is that you can have > multiple applications (appIds) for a single package. And application > framework guys can go crazy like wanting those apps to be installed > independently or even idependently uninstalled, upgraded or added. > Securityframework in Tizen 3 was designed to be ready for such requirements, > even if they aren't needed at the moment. my point is... "it's crazy". it is an app - the front end and back end are intrinsically tied together as an app. if the front end has a new feature, the back end has to go support it, for example. they may change protocol just like any app may change it's internal apis during a release. it's trying to de-couple something that probably shouldn't be. *IF* the back-end is some general "service" anyone can use (and thus is an app in its own right) and the front end is just one of multiple clients (for example), then we have a different situation. the back-end guys are developing a "public service" with a documented and "stable" api. this is a far different set-up than "hybrid app" and here everything ships as separate apps entirely disjoint from eachother, and there is no need for packaging to know or care beyond perhaps a dependency and appropriate smack permissioning so any client of this service can connect to the back-end. -- Carsten Haitzler (The Rasterman) <[email protected]> _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
