Activation: b-a-s problems.

[Michael Meeks]

On Mon, 2004-01-05 at 17:06, Havoc Pennington wrote:
> Similarly for language issues, start the service always with the session
> language, but if necessary let someone request a resource in another
> language. e.g. gconfd can serve values for multiple languages.

	Sure; however - this instantly removes gettext from the picture, and we
all have to start re-writing that code in new, odd &&|| less efficient
ways - which is not pleasant, and creates a need for things like
'intltool'.

> Does this imply that service activation should never have _parameters_
> that affect the nature of the service that was started?
> I think it probably does. Activation parameters should only affect which
> services to start, not what the services are like.

	Well; ultimately - this just moves the problem. It moves it from
activation time to method invocation time (at which point the app has to
know what context a given method is going to require), i18n is one,
others are perhaps harder to think of: AUDIODEVICE perhaps ? and of
course the display/screen stuff for anything with 1/2 a chance of doing
something that causes a dialog to be thrown up.

	It's fair enough to push it to method invocation, and nice to hope that
all services will cope with arbitrarily broard contexts. Indeed perhaps
i18n is not so important / difficult for simple services, however this
is one nastily problematic area that we ran into with bonobo. I forget
if D/BUS allows/encourages the use of exceptions / user-readable return
strings - does it ?

	Regards,

		Michael.

-- 
 michael@ximian.com  <><, Pseudo Engineer, itinerant idiot