Re: heads up on 84897 and dependencies

[Bill Haneman <bill haneman sun com>]

On Mon, 2002-06-17 at 09:33, Michael Meeks wrote:
> Hi Bill,
...
>       This is notably binary compatible, indeed it removes but
> 1 flag from the -common.c file. Having studied it in some considerable
> depth, there is no option but to do this.
>
>        This also, potentially has ramifications due to adding 
> uncontrolled re-enterancy during various events which at-spi 
> proxies on via the wire. So potentially we'd need to add a push/pop
>re-enterancy method to ORBit2- potentially as well.

OK, this part worries me considerably; this is ORB-dependent API which I
don't want to put into the stack.  It also probably would break lots of
accessibility stuff since synchronous calls *will* have to be serviced
when responding to our event notifications; it's not clear to me that
this is feasible.

An alternative might be to require clients to queue their at-spi events
(most are doing this already, to avoid their own reentrancy issues),
however that requires that the client ref() the event source on receipt
of events that it wishes to retain (see below).  Simple filtering could
occur before queueing, but in many cases the listener would have to call
back into the event server.

> > Since we should then remove the ref() and the requirement
> > for the called server to unref() after servicing the call, this will
> > require changes to apps using our API (currently only apps under our
> > direct control, and GOK and gnopernicus).
> 
> 	What ? there is no problem with the ref/unref - and that should have no
> API or other problems associated - I don't understand what that's all
> about.

We are doing ref()/unref() pairs on every event dispatch - at least
twice, since we do it again when the registry relays the event to any
listeners.  This is because we must persist the source of the event on
the client side until the listener (server) is done with it; with async
calls that means we must ref() the source object and wait for the
listener to unref() it.

With synchronous notification this is unnecessary, we need not increment
the object refcount before event dispatch.  Changing from oneway would
make our current ref()/unref() pairs quite pointless for cases where the
listening client does not cache/retain the event source for later use.

It's fine as far as I am concerned to make our clients depend on a later
at-spi library rev, but it means that they'd have to update this part of
the GNOME 2.0.0 stack in order to work properly.

However given the current state of affairs they won't reliably work
properly anyway ;-) due to crashing the ORB with excess oneways.

> >  However this means that. despite bincompatibility, if we do this we
> > should do it at 2.0.0 (i.e. *now*) and not 2.0.1.
> 
> 	I totally disagree. I don't believe it's at all necessary to delay the
> release for this.
> 
> > A small worry; we padded our IDL with extra epv calls for expansion, but
> > forgot to pad the EventListener IDL, which is the one that needs
> > changing.  So if we might someday want to restore a notifyAsync() call
> > or something, we should pad the IDL now too.
> 
> 	Again; no need for that, it's quite possible (indeed fairly trivial) to
> invoke synchronous calls asynchronously, so that should be no problem.
> Indeed, quite the opposite over-reliance on oneway is a nasty problem.

Hmm, well oneway is the only ORB-independent way of specifying this, so
I still think we may want it in the future.

-Bill
 
> 	Regards,
> 
> 		Michael.
> 
> -- 
>  mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot
>