OLPC and .service files in a users home directory

[uwesmail2005-lkml at yahoo.de]

--- "John (J5) Palmieri" <johnp at redhat.com> schrieb:

> An issue arose within OLPC dealing with activating activities.  In
> OLPC's sugar environment we use D-Bus extensively for activating what
> we
> call activities.  Activities are just apps that integrate with the
> sugar
> environment.  We are moving away from the traditional install
> everything
> in system directories to what we call bundles which are a lot like
> the
> MacOSX app bundles in that they are self contained and installing
> them
> is a matter of copying to the correct directory.  
> 
> This presents a problem to D-Bus activation in that we do not have
> access to write to the /usr/share/dbus-1/service directory.  What we
> want the ability to do is have sugar generate the .service files from
> the activity bundles and place them in a directory in the users home.
>  I
> think this should also be in the default system.conf.  We already
> have
> an xdg autostart directory in the users home so this does not present
> any security issues but it would allow the user to override default
> handlers for a specific service if they wanted to (say the
> notification
> daemon for instance).
> 
This automatically arises from my ideas as set forth in the thread
"[rfc] The Big Picture". When you use the upstart program as
decribed there as session manager it could detect that it doesn't run
as root and therefore include that users homedir in its search path
for the service dir. Or the users session manager could understand
the D-Bus activation messages and read from gconf (or where ever) what
to do.
Some unrelated idea: Absolute Pathnames for service dir are used as is.
Relative Pathnames are searched along a path that is configured
elsewhere in the system. And in this config there could be env vars or
passwd fields or whatever.
> There are a couple of ways we can go about this.  We can expand
> variables in the path that start with the dollar sign (e.g.
> <servicedir>$HOME/.dbus/service</service>) or add a special tag (e.g.
> <servicedir><homedir />/.dbus/service</service>).
> 
> The former is more flexible but would require a separate config file
> in
> windows. The latter allows us to hide platform specifics in the conf
> file but breaks the dtd and isn't nice to look at.  I think the real
> question is do we want to allow random env variable or just restrict
> it
> to the users home directory?
> 
> -- 
> John (J5) Palmieri <johnp at redhat.com>
> 
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
> 





	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de