> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Carsten Haitzler > Sent: Monday, March 10, 2014 7:41 PM > To: [email protected] > Subject: Re: [Dev] [Multiuser] gumd further work (reject) > > > On 03/11/2014 09:45 AM, Schaufler, Casey wrote: > >> -----Original Message----- > >> From: Carsten Haitzler [mailto:[email protected]] > >> Sent: Monday, March 10, 2014 5:05 PM > >> To: Dominig ar Foll (Intel OTC) > >> Cc: Schaufler, Casey; Leonard Milcin; [email protected] > >> Subject: Re: [Dev] [Multiuser] gumd further work (reject) > >> > >> On Mon, 10 Mar 2014 17:24:42 +0100 "Dominig ar Foll (Intel OTC)" > >> <[email protected]> said: > >> > >>> Hi, > >>> > >>> until said otherwise, I am the architect in charge of Multi User and > >>> I will repeat for those who missed it, what I said in an earlier mail. > >>> > >>> I do not think that the model of adding, to the module in charge of > >>> creating new users in the system (useradd, gumd or any other), App > >>> specific user resource creation tasks such as DB, directories, > >>> config files, ... > >>> Such model is an ugly hack, which will break rather earlier than later. > >>> > >>> Application knows what resources they need in relation to a specific > >>> user at installation as well as later during update or upgrade. > >>> > >>> Those tasks need to stay with the Apps themselves. > >>> > >>> Until someone convince me that I am incorrect in my statement about > >>> risk on system stablity on the long term, I will not accept to off > >>> load these App specific resources creation to the useradd service in > Tizen. > >>> > >>> Apps developpers, that is your job. > >> I would agree. it's the job of an app to work with an entirely empty > >> user directory, and work sensibly. what "sensible" is isa matter for > >> the app in question. if the app insists on having a database in the > >> user homedir - then app must create it if db not found and populate > >> it with initial data. if db is corrupt - app must "deal with it" (fix > >> db, nuke it and start again etc.). same for config etc. > > Perfectly sensible once we address the case where two apps want to use > > a file named "Configuration". Does the first app get it? The second? > > If we agree on a convention that all application specific files go in > > the application's directory (or some other differentiation) we'll be > > fine. But we need to do that, and be clear about it. > > i would have thought that was already assumed.
I know better than to assume that no two developers think that calling a file "conf" is a good idea. That is the kind of assumption that leads to big surprises. Let us be paranoid and be ready for people doing things we wouldn't. > 2 apps sharing the same > config is just asking for trouble unless they carefulyl negotiate ownership > with locks etc. - and if they do then they're fine. if they don'tthey have > inherent bugs already that need fixing regardless and this is a good "kick in > the behind" to force those to be fixed. :) > > > > > > >>> Dominig ar Foll > >>> Senior Architect > >>> Intel Open Source Technology Centre > >>> > >>> > >>> _______________________________________________ > >>> Dev mailing list > >>> [email protected] > >>> https://lists.tizen.org/listinfo/dev > >>> > >> > >> -- > >> Carsten Haitzler (The Rasterman) <[email protected]> > > _______________________________________________ > > Dev mailing list > > [email protected] > > https://lists.tizen.org/listinfo/dev > > > > -- > The above message is intended solely for the named addressee and may > contain trade secret, industrial technology or privileged and confidential > information otherwise protected under applicable law including the Unfair > Competition Prevention and Trade Secret Protection Act. Any unauthorized > dissemination, distribution, copying or use of the information contained in > this communication is strictly prohibited. If you have received this > communication in error, please notify the sender by email and delete this > communication immediately. > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
