Re: [g-a-devel]Implementing support for state sets in at-spi

[Marc Mulcahy <marc mulcahy sun com>]

I'd forsee states being used quite a bit, since we convey info like 
"checked" and "editable" using them.  I'll try to come up with a proposal 
unless someone else has one offhand...

Marc

At 02:06 PM 2/11/2002 +0000, Michael Meeks wrote:
> Hello Bill,
>
> On Mon, 2002-02-11 at 10:55, Bill Haneman wrote:
> > >         So - I imagine you need some IDL method or other to marshal 
> the thing
> > > to a sequence of some semi-private type, and then you'll need to compare
> > > them in isEqual.
> > >
> > >         How does that sound ?
> >
> > Like overkill ;-)
>
>         Fascinating; tell me how you expect to compare a local and a remote
> StateSet ? and the sequence of round trip CORBA method latencies.
>
> > At least in many situations I think the StateSet can just be
> > an opaque object, only the "states" are exposed (and the methods,
> > contains, equals, etc.)
>
>         It's not so much about Objects, but interfaces - thus really, to do
> anything like 'equals' or 'contains' efficiently you need to be able to
> pass the whole state across the inter-process barrier efficiently - or
> pay the price of using the interface iteratively which sounds uber-slow
> for state sets (to me).
>
> > Actually I am not sure we need to marshal a special struct here.
> > At least it didn't appear to require that much API last time I
> > looked at it; I'll look again.
>
>         My feeling is we can have horribly inefficiency or IDL changes, 
> and I'd
> plonk for the latter - it all depends how much we need to use StateSets
> really.
>
>         Regards,
>
>                 Michael.
>
> --
>  mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot