On 03/11/2014 11:51 AM, Schaufler, Casey wrote:
-----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.
if you are unable to handle namespacing your data for your app... use
some config api/abstraction/system that does this for you instead... :)
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
--
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