Activation: b-a-s problems.

[Havoc Pennington]

On Mon, 2004-01-05 at 12:12, Michael Meeks wrote:
> 	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'.

If gettext means a single process can only serve one language, then I
see these options:

 1. The service "name" (name = full identifying information) contains 
    the language and we start a process per language

 2. We fix gettext, perhaps with GTK support for something like a 
    language per toplevel window

 3. For now we just dictate that you have to use the same language for 
    the whole session (seems more feasible in a Unicode age)

 4. When feasible we can include the language in requests, as with gconf

The option I don't like is:

 5. The service with name "foo" can be in language A or B depending on 
    where/how it was activated

I don't think option 5 works around the gettext problem, anyhow, it just
happens to work with "LANG=foo bar" if bar hasn't been launched yet.

So what I'm saying is, if we want a service named "Spreadsheet,LANG=foo"
then that's fine, but if we want a service named "Spreadsheet" with LANG
determined by the activator, that seems broken.

> 	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.

My basic feeling is that environment variables need to lose in most
cases. AUDIODEVICE for example should just be a global
dynamically-modifiable configuration option. Language might be ideally,
though it won't ever happen due to infeasibility.

If we have a generic "unique application" facility, then that should
cover the display/screen issue.

> 	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 ?

Yes, it does.

Havoc