Hi Mark,
On Tue, 2007-12-11 at 11:46 +0000, Mark Doffman wrote:
> > What do I mean about compatibility ? cf. the mess around 'Event'
> > 'EventDetails' etc. If we can have a 'struct' that simply grows as we
> > add more fields to it, and gets padded with 0's as mismatches occur: we
> > have an incredibly nice compatibility story. The stock non-answer to
> > this is "ah yes, if you hand-write all your marshallers / de-marshallers
> > - you can get that already !" ;-) which leads to point b):
>
> Ok, I think I get whats going on here. I imagine this is more about the
> marshaller / de-marshaller code not throwing a wobbly when there is data
> appended to the message that it doesn't expect. Its certainly something
> to think about.
Right; also, not just appended - but appended to eg. a structure that
is argument 3 of 5 could get extended too, or a structure that is a
member of a structure (hopefully all handled in a clean & generic way).
> I guess if there was such a tool already available.. Such as the
> modified version of your perl one :), then it wouldn't be such an
> issue.
Heh - that perl is ancient, but perhaps workable in some form.
> In ORBit the type gets passed with the object reference. This prodded us
> into a bit of a think on the D-Bus side. You're right, we don't want to
> go introspecting every new object we see just to get the methods
> available on it. I guess this implies some sort of interface repository
> (lets rebuild corba!), along with passing a type signature.
So ;-) of course, the flip side of not having a fixed type scheme means
we can (I guess) pass a bit-field (or human-readable-char-field) with
each reference saying what interfaces it supports - to reduce
synchronous query-interface traffic (?).
> > Another query - wrt. lifecycle mechanisms: what would be proposed for
> > lifecycle tracking object peers inside providing applications ?
>
> No proposals. ATM I'm imagining that all AT-SPI objects die with their
> applications, and not otherwise. If anyone has some examples of where
> this can't be the case we really need to know.
Quite - there are lots of examples. Basically we need to keep state in
the application for atk peers - they are created, and (AFAIR) they are
needed to keep around for various things.
That would be fine, since we have a nice strong lifecycle mechanism -
the window's visibility ;-) unfortunately at this point Documents
arrive:
*Unfortunately* - various creative types decided that what the world
really needs is to expose the entire DOM, though the main use for this
is for the blind. Thus, instead of exposing just the visible area [ plus
some nice 'page-down / next-heading' style navigation interface ], we
expose a potentially infinite space :-) The problem with that is that we
-have- to have explicit lifecycle management (of some form) [ or use
custom references & transient objects of some form - which is hard on
atk. ].
So the punch line is - (IMHO etc.) we have an unfortunate interface
that demands explicit lifecycle, that creates extra round-trips,
cross-process reference leaks, and various other nightmares :-) And -
get this: the main use-case (AFIACS) is for braille displays which often
have 2x lines of <N> character text: ie. way less than is visible (or
could easily be made visible).
> I'm sure we could go the Bonobo route and have a base class that was
> reference counted, but we really don't want to.
Quite - me neither ;-) OTOH, it's a hard issue to fix: and
precedent-wise, MSAA, IAcc2, UIA, UNO a11y and atk use reference
counting :-)
> > > ** D/BUS should use it's native type system to describe
> > > types instead of a foreign one **
>
> Damn straight. I really like this. Anyone for
> getNativeIntrospectionData()?
:-) glad you like it - of course requires the extensibility thing to be
as 'good' as XML.
All the best,
Michael.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
_______________________________________________
Gnome-accessibility-devel mailing list
Gnome-accessibility-devel@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
