Re: a proposal for 2 OAF features

[Jaka Mocnik <jaka mocnik kiss uni-lj si>]

Elliot Lee wrote:

> > >          /* ActivationResult */
> > >          enum ActivationResultType {
> > >                  RESULT_OBJECT,
> > > @@ -87,6 +87,7 @@
> > >                  REG_SUCCESS,
> > >                  REG_NOT_LISTED,
> > >                  REG_ALREADY_ACTIVE,
> > > +                REG_EXCLUSIVE,
> > >                  REG_ERROR
> > >          };
> 
> The meaning of and need for this additional ActivationResult is very
> unclear.
merely something to distinguish the case when the object was activated
exclusively.

> > > +extern gboolean oaf_exclusive;
> 
> A global variables is very broken for this case. Multiple objects might be
> activated in the same process. You have to do implement exclusivity only
> for the object activated from the command line.
fine, how about --oaf-exclusive=IID and a gchar *exclusive_iid then?

> These two hunks are totally incorrect. oaf-servreg is not related to
> activated object registration.
ekhm. as far as I could understand the code, oaf_active_server_register
is precisely the function that registers the new server with OAF. so how
come oaf-servreg is not related to activated object registration?

> Use of params to factories is deprecated - please do not use. Factories
> are not supposed to register with OAF any of the objects they create
> (although for apps like gnumeric they will certainly want to register the
> object in another place such as the name service). If one wishes to have
> the factory return the same object for multiple activations, that logic
> needs to be coded into the factory object. The point of factories is
> basically to allow implementing custom activation logic beyond what OAF
> allows.
OK, nice to have this one cleared out.

regards,
	jaKa

-- 

email: jaka.mocnik@kiss.uni-lj.si
w3:    http://pluton.ijs.si/~jaka