Re: [g-a-devel]Implementing support for state sets in at-spi
- From: Bill Haneman <bill haneman sun com>
- To: Michael Meeks <michael ximian com>
- Cc: Marc Mulcahy <marc mulcahy sun com>, accessibility mailing list <gnome-accessibility-devel gnome org>
- Subject: Re: [g-a-devel]Implementing support for state sets in at-spi
- Date: Mon, 11 Feb 2002 15:01:55 +0000
Michael Meeks wrote:
>
> Hello Bill,
> Fascinating; tell me how you expect to compare a local and a remote
> StateSet ? and the sequence of round trip CORBA method latencies.
...
> 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.
The intention was for these operations to be opaque. I agree that we
need some
kind of data marshalling but my intention was never to expose it; one
reason has
to do with language bindings, another was the desire not to expose
implementation-dependent
marshalling/demarshalling code.
That said, the implementation code for compare and isEqual would like
*some*
way to do its work efficiently, without having to call 'contains'
multiple times. Do we have a convention for doing this, i.e. for
"private"
IDL methods? That's what we'd want here I think.
We could have Accessibility_StateSet implement some OpaqueAny thingy
kind of
interface which user code would expressly not be able to do anything
useful with, but perhaps we can just add a getPackedData method to
StateSet, with the proviso that user code shouldn't muck with it?
Regards,
Bill
> Regards,
>
> Michael.
>
> --
> mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]