Re: a proposal for 2 OAF features



Elliot Lee wrote:
> 
> On Mon, 3 Jul 2000, Jaka Mocnik wrote:
> 
> > I've got two proposals concerning the OAF implementation:
> >
> > 1. currently, only one active server per IID can be registered in the
> > ObjectDirectory. I think that the per_iid hashtable should store a
> > GList for each IID, containing all registered active servers (ie, if
> > multiple servers are activated using the OAF_FLAG_IGNORE_EXISTING
> > flag). with each registration a new server would be prepended to this
> > list and with each activation of an already existing server, the
> > server at the head of the list would be activated and moved to the
> > tail. this would serve as a simple balancing algorithm.
> 
> This is broken as-is - the semantics are undefined, etc. If you wish to do
> activation from a pool of objects, activate a factory via OAF and then the
> individual objects via a custom interface.
why exactly is this broken? is it saner that each object simply
disappears from OAF when a new server with the same IID is activated? if
the IGNORE_EXISTING flag were replaced by EXCLUSIVE (see below), then
that would perhaps make sense as only one
server per (IID, host)-pair could be spawned by OAF.

> > 2. I think that OAF should add an option to _only_ activate and _not_
> > register the server (something like a flag OAF_FLAG_EXCLUSIVE) in
> > order to enable an application to use the activated server
> > exclusively. this implies IGNORE_EXISTING. as the registration is done
> > by the server and not OAF, it would mean passing a command line
> > argument to the server exe (let's call it "--oaf-exclusive") or a
> > parameter to the Factory object. I don't know what to do with shared
> > libs for this purpose.
> 
> I think this is mostly what the IGNORE_EXISTING flag means in practice -
> give me an object that no-one else will use. So a bug fix there and
> perhaps a clarification interfacewise would be better than keeping
> IGNORE_EXISTING with same meaning.
then perhaps, the IGNORE_EXISTING flag should be replaced by EXCLUSIVE
flag. but the remaining problem is that the server activated in this
manner registers itself, promptly replacing the possible previously
registered one and is available at next activation, possibly for another
process. it seems that there is need for a cmdline arg like
--oaf-exclusive to tell liboaf NOT TO register the server (effectively
replacing the possible already registered one) when
oaf_active_server_register() is called.

regards,
	jaKa

-- 

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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]