D-Bus AT-SPI - The way forward

[Mark Doffman]

Hello all,

Available at http://live.gnome.org/GAP/AtSpiDbusInvestigation is the
results of an investigation into a move of the AT-SPI interface to a
D-Bus transport. The investigation mainly looks at the relative
performance of ORBit and D-Bus, but also details some architectural
issues and a preliminary task list.

In brief:

Performance:

GOK and Orca were profiled to get a good idea of the type of traffic on
the AT-SPI interface. Using this information the performance of some of
the most common method calls were tested in D-Bus and ORBit.

D-Bus is undoubtedly slower at most of the common method calls, 5-6x
slower when making a call that passes one int as an argument. When
passing more data per call this speed difference decreases. ORBit takes
a long time to pass an Object reference, making D-Bus up to 1.5x faster
at these method calls.

Although D-Bus is the slower transport, looking at the calls made by
Orca and GOK, we feel it will be possible to provide sensible caching
that should mitigate this effect.

Tasks:

For a switchover to D-Bus a number of core libraries will need to have
the transport mechanism changed: cspi, pyatspi, GAIL. There will also
need to be a new Java accessibility back end. Some core D-Bus work is
also needed, in the areas of interface specification, bindings and
possibly optimisation.

If you are interested please go and take a look at the wiki page. We'd
really like to get every ones opinion on what the way forward for AT-SPI
is in terms of its transport mechanism.

Thanks

Mark

--
Mark Doffman, Codethink Ltd. - http://codethink.co.uk

_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility

[Aaron M Leventhal]

Mark, did you try testing Orbit with a direct connection?
This suggestions was from George Kraft:

> How are your Orbit2 results impacted if your $HOME/.orbitrc has set
> the following?
>
> ORBIIOPIPv4=1
> ORBLocalOnly=1

- Aaron

Mark Doffman <mark.doffman@...>
Sent by: accessibility-atspi-bounces@...

12/05/2007 11:56 AM

To	accessibility-linux-foundation <accessibility@...>, accessibility-atspi-linux-foundation <accessibility-atspi@...>, gnome-accessibility-devel <gnome-accessibility-devel@...>, kde-accessibility <kde-accessibility@...>
cc
Subject	[Accessibility-atspi] D-Bus AT-SPI - The way forward

Hello all,

Available at http://live.gnome.org/GAP/AtSpiDbusInvestigation is the
results of an investigation into a move of the AT-SPI interface to a
D-Bus transport. The investigation mainly looks at the relative
performance of ORBit and D-Bus, but also details some architectural
issues and a preliminary task list.

In brief:

Performance:

GOK and Orca were profiled to get a good idea of the type of traffic on
the AT-SPI interface. Using this information the performance of some of
the most common method calls were tested in D-Bus and ORBit.

D-Bus is undoubtedly slower at most of the common method calls, 5-6x
slower when making a call that passes one int as an argument. When
passing more data per call this speed difference decreases. ORBit takes
a long time to pass an Object reference, making D-Bus up to 1.5x faster
at these method calls.

Although D-Bus is the slower transport, looking at the calls made by
Orca and GOK, we feel it will be possible to provide sensible caching
that should mitigate this effect.

Tasks:

For a switchover to D-Bus a number of core libraries will need to have
the transport mechanism changed: cspi, pyatspi, GAIL. There will also
need to be a new Java accessibility back end. Some core D-Bus work is
also needed, in the areas of interface specification, bindings and
possibly optimisation.

If you are interested please go and take a look at the wiki page. We'd
really like to get every ones opinion on what the way forward for AT-SPI
is in terms of its transport mechanism.

Thanks

Mark

--
Mark Doffman, Codethink Ltd. - http://codethink.co.uk

_______________________________________________
Accessibility-atspi mailing list
Accessibility-atspi@...
https://lists.linux-foundation.org/mailman/listinfo/accessibility-atspi


_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility

[Mark Doffman]

Hi Aaron,

Sorry for repeat, managed to not cc lists last time.

On Wed, 2007-12-05 at 12:30 -0500, Aaron M Leventhal wrote:
>
> Mark, did you try testing Orbit with a direct connection?

All of the ORBit calls are direct. To clarify, in the D-Bus case all
connections made are using local unix sockets. In the non-direct case
messages are passed to an intermediate process, the bus-daemon, before
being forwarded on to their destination.

> This suggestions was from George Kraft:
>
> > How are your Orbit2 results impacted if your $HOME/.orbitrc has set
> > the following?
> >
> > ORBIIOPIPv4=1
> > ORBLocalOnly=1

I was running without an .orbitrc file, so the standard properties in
the code were used. The standard setup is to use unix sockets
(ORBIIOPUsock=1). Adding the configuration above, and disabling USock
caused worse performance. (Approx 10% slowdown). Simply adding the lines
above without disabling USock didn't make much of a difference.

Mark

>
> - Aaron
>
>
>
> Mark Doffman
> <mark.doffman@...>
> Sent by:
> accessibility-atspi-bounces@...
>
> 12/05/2007 11:56 AM
>
>
>                To
> accessibility-linux-foundation <accessibility@...>, accessibility-atspi-linux-foundation <accessibility-atspi@...>, gnome-accessibility-devel <gnome-accessibility-devel@...>, kde-accessibility <kde-accessibility@...>
>                cc
>
>           Subject
> [Accessibility-atspi] D-Bus AT-SPI - The way forward
>
>
>
>
>
>
>
>
> Hello all,
>
> Available at http://live.gnome.org/GAP/AtSpiDbusInvestigation is the
> results of an investigation into a move of the AT-SPI interface to a
> D-Bus transport. The investigation mainly looks at the relative
> performance of ORBit and D-Bus, but also details some architectural
> issues and a preliminary task list.
>
> In brief:
>
> Performance:
>
> GOK and Orca were profiled to get a good idea of the type of traffic
> on
> the AT-SPI interface. Using this information the performance of some
> of
> the most common method calls were tested in D-Bus and ORBit.
>
> D-Bus is undoubtedly slower at most of the common method calls, 5-6x
> slower when making a call that passes one int as an argument. When
> passing more data per call this speed difference decreases. ORBit
> takes
> a long time to pass an Object reference, making D-Bus up to 1.5x
> faster
> at these method calls.
>
> Although D-Bus is the slower transport, looking at the calls made by
> Orca and GOK, we feel it will be possible to provide sensible caching
> that should mitigate this effect.
>
> Tasks:
>
> For a switchover to D-Bus a number of core libraries will need to have
> the transport mechanism changed: cspi, pyatspi, GAIL. There will also
> need to be a new Java accessibility back end. Some core D-Bus work is
> also needed, in the areas of interface specification, bindings and
> possibly optimisation.
>
> If you are interested please go and take a look at the wiki page. We'd
> really like to get every ones opinion on what the way forward for
> AT-SPI
> is in terms of its transport mechanism.
>
> Thanks
>
> Mark
>
> --
> Mark Doffman, Codethink Ltd. - http://codethink.co.uk
>
> _______________________________________________
> Accessibility-atspi mailing list
> Accessibility-atspi@...
> https://lists.linux-foundation.org/mailman/listinfo/accessibility-atspi
>

--
Mark Doffman, Codethink Ltd. - http://codethink.co.uk

_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility

[George Kraft]

> D-Bus case all connections made are using local unix sockets.

How will a D-Bus version of AT-SPI handle sudo (local non $USER owned
applications displaying to $DISPLAY) and remote applications ($USER and
non $USER owned applications displaying to $DISPLAY) work?

George (gk4)



_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility

[Rob Taylor-3]

George Kraft wrote:
>> D-Bus case all connections made are using local unix sockets.
>
> How will a D-Bus version of AT-SPI handle sudo (local non $USER owned
> applications displaying to $DISPLAY) and remote applications ($USER and
> non $USER owned applications displaying to $DISPLAY) work?

A good question. The 'connection address' of the session bus is an
environment variable, usually setup by Xsession. So all programs run
within one Xsession will connect to the session bus for that X session,
regardless of $USER.

In terms of remote applications, there is a plain TCP transport, and
when using this authentication happens by means of tokens in the users
home directory, so it should work fine in a thin client situation.

Thanks,
Rob

> George (gk4)
>
>
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel@...
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel


--
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk
_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility

[Rob Taylor-3]

Rob Taylor wrote:

> George Kraft wrote:
>>> D-Bus case all connections made are using local unix sockets.
>> How will a D-Bus version of AT-SPI handle sudo (local non $USER owned
>> applications displaying to $DISPLAY) and remote applications ($USER and
>> non $USER owned applications displaying to $DISPLAY) work?
>
> A good question. The 'connection address' of the session bus is an
> environment variable, usually setup by Xsession. So all programs run
> within one Xsession will connect to the session bus for that X session,
> regardless of $USER.
>
> In terms of remote applications, there is a plain TCP transport, and
> when using this authentication happens by means of tokens in the users
> home directory, so it should work fine in a thin client situation.

I should add, there is an issue when running applications remotely via
ssh. The preferred solution in this case is to add support to ssh for
forwarding the dbus connection and setting the envvar on the remote end,
exactly as happens with X11 and $DISPLAY now. Does AT-SPI currently cope
in this situation and if so, how?

Thanks,
Rob

> Thanks,
> Rob
>
>> George (gk4)
>>
>>
>>
>> _______________________________________________
>> Gnome-accessibility-devel mailing list
>> Gnome-accessibility-devel@...
>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>
>

--
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk
_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility

[Li Yuan]

As I remembered, at-spi can work with ssh -x if set orbitrc on both
client and server correctly.

Li


On 四, 2007-12-06 at 15:16 +0000, Rob Taylor wrote:
> I should add, there is an issue when running applications remotely via
> ssh. The preferred solution in this case is to add support to ssh for
> forwarding the dbus connection and setting the envvar on the remote
> end,
> exactly as happens with X11 and $DISPLAY now. Does AT-SPI currently
> cope
> in this situation and if so, how?

_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility

[Olaf Schmidt-2]

[ George Kraft, Do., 6. Dez. 2007 ]
> > D-Bus case all connections made are using local unix sockets.
>
> How will a D-Bus version of AT-SPI handle sudo (local non $USER owned
> applications displaying to $DISPLAY) and remote applications ($USER and
> non $USER owned applications displaying to $DISPLAY) work?

We discussed these cases in detail at the KDE conference last year with Bill
Haneman and Harald Fernengel.

We quickly found that it is possible to simply reuse the existing
authentification methods used by CORBA. I am not personally familiar with the
implementation details of CORBA, but I know that a summary of out discussion
result is availiable in the OpenA11y wiki and mailing list archive. I look
this up tomorrow or the day after tomorrow.

David from Red Had later suggested ssh-forwarding as an alternative option.

Olaf
_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility

[George Kraft]

On Sun, 2007-12-09 at 14:44 +0100, Olaf Schmidt wrote:
> We quickly found that it is possible to simply reuse the existing
> authentification methods used by CORBA.

Would it make sense to get performance numbers for local and networked
AT-SPI over Orbit2 versus D-Bus?    Does setting $HOME/.xorbitrc change
the local performance results for Orbit2?  I run with these settings all
the time.

ORBIIOPIPv4=1
ORBLocalOnly=1

--
George (gk4)


_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility

[Rob Taylor-3]

George Kraft wrote:

> On Sun, 2007-12-09 at 14:44 +0100, Olaf Schmidt wrote:
>> We quickly found that it is possible to simply reuse the existing
>> authentification methods used by CORBA.
>
> Would it make sense to get performance numbers for local and networked
> AT-SPI over Orbit2 versus D-Bus?    Does setting $HOME/.xorbitrc change
> the local performance results for Orbit2?  I run with these settings all
> the time.
>
> ORBIIOPIPv4=1
> ORBLocalOnly=1
>

In case you missed Mark Doffman's earlier mail, I'll quote it here:

> I was running without an .orbitrc file, so the standard properties in
> the code were used. The standard setup is to use unix sockets
> (ORBIIOPUsock=1). Adding the configuration above, and disabling USock
> caused worse performance. (Approx 10% slowdown). Simply adding the lines
> above without disabling USock didn't make much of a difference.

i.e. an orbitrc of

OBITIIOPIPv4=1
ORBLocalOnly=1

is roughly 10% slower than

ORBITIIOPUsock=1

(on a linux system, in this case)

We could test DBus over tcp (non-local) against ORBit over TCP
(non-local), though I'm not sure how common a use-case this is.

I'd expect that the numbers would get more similar between the dbus and
orbit versus using unix sockets, as the time spent in transport would
come to dominate. Message sizes are roughly similar between the two
technologies and almost always would be under MTU.

Thanks,
Rob

--
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk
_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility

[michael meeks]

Hi Mark,

On Wed, 2007-12-05 at 16:56 +0000, Mark Doffman wrote:
> Available at http://live.gnome.org/GAP/AtSpiDbusInvestigation is the
> results of an investigation into a move of the AT-SPI interface to a
> D-Bus transport

        It's most interesting.

> D-Bus is undoubtedly slower at most of the common method calls, 5-6x
> slower when making a call that passes one int as an argument. When
> passing more data per call this speed difference decreases.

        This is simultaneosly pleasing & distressing. That D-BUS hasn't
apparently progressed performance-wise to the (non-optimised) state of
ORBit2 (effectively in deep-sleep/maintenance mode for the last 4 years)
is somewhat surprising. I wonder what is going on there, must be a silly
or two in the marshalling logic.

>  ORBit takes a long time to pass an Object reference, making D-Bus up
> to 1.5x faster at these method calls.

        I can believe it; CORBA object references are quite verbose -
particularly (as you note) when multiple transports are added: IP / Unix
etc.

> Although D-Bus is the slower transport, looking at the calls made by
> Orca and GOK, we feel it will be possible to provide sensible caching
> that should mitigate this effect.

        Quite - ultimately, the choice of transport is moot IMHO, though
clearly unifying on a single shared transport layer is a great direction
even if, for mindless political reasons, it has to be "not CORBA".

> For a switchover to D-Bus a number of core libraries will need to have
> the transport mechanism changed: cspi, pyatspi, GAIL. There will also
> need to be a new Java accessibility back end. Some core D-Bus work is
> also needed, in the areas of interface specification, bindings and
> possibly optimisation.

        Right; so I guess the sticking point is only Java.

        Wrt. core D-BUS work: one of the reasons I was actually enthusiastic
about a switch to D-BUS is that it marshals types on the wire: that
*should* allow an extremely sexy forward & backwards compatibility story
to be developed: that is impossible with CORBA. Unfortunately, it seems
that's been mostly ignored despite my attempts to communicate that:
generating a shared goal of that for a11y would be really useful.

        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):

        The bindings must be good, and need to be generated from some sort of
sane & readable (preferably IDL-like) interface description. I wrote a
prototype one in perl long ago, not sure if it's rescue-able ;-)

        Anyhow, the "D/BUS thoughts" I wrote in 2005 is attached, somehow it
managed not to get moderated when I re-posted it to the D-BUS list some
year or so later; perhaps it's only of historical interest now.

        One last concern - was anonymous objects & the problems of type
introspection (round-trip-wise). Do we marshal the interface type of an
object with it's reference ? [ bit rusty here ].

        Another query - wrt. lifecycle mechanisms: what would be proposed for
lifecycle tracking object peers inside providing applications ?

        Anyhow - in general, IMHO etc. moving to D-BUS is a positive move, and
[ I guess ], the mercy (I hope) is that it can be done without excessive
disription to the Python or cspi bindings, and no pain for atk either. I
guess as Novell spins up it's a11y team here, we -may- be able to help
out with some of the work / testing - though that's unclear as yet. I'd
love to follow the design & impl. of the work myself anyhow.

        HTH,

                Michael.

--
 michael.meeks@...  <><, Pseudo Engineer, itinerant idiot


Hi Havoc,

        So - at LWE I said I'd scribble down a few notes wrt. things I
was hoping would get done in D/BUS; most pleased to see the recursive
type support. Please do forward to the list if you think any of it is
useful.

        So - this is informed by the work on ORBit2; we learned a
number of interesting things there over the course of a few years.
hopefully some of these are by now fixed in D/BUS etc.

* Some lessons:
        + don't create new type systems
                + people hate to convert between representations
                + people hated (the type-safe, powerful etc.) CORBA
                  type system; because they had to convert between
                  GArray & CORBA_sequence_Foo

        + use a recursive type system
                + all programming languages have them, for good
                  reason.
                + they allow a nice, simple mapping to many
                  languages.

        + a corrolory of that is:
                + don't proliferate representations
                        + you will always need a native
                   representation of XYZ information
                        + if you structure that representation to
                          conform to your type system - you avoid
                          creating 'yet another representation'
                + ie. it's not a strength to represent type data in
                  IDL, and XML, and 1-per-language native parsed
                  forms. Far better to use a common representation
                  based on the type system.
                + IPC shouldn't be _that_ difficult, or require
                  _that_ much code
                + reducing redundant representations helps to
                  substantially reduce code complexity & ease
                  maintenance.

        Anyhow - here were some of my thoughts of several months ago
when I last looked at D/BUS:

    * Extensibility
        + One thing I really like about D/BUS that CORBA was
          missing is the extensibility allowed by the marshalling
          of type information on the wire. ie. a D/BUS call
          would look (in CORBA) like:
                callMethod( in string name, in sequence<Any> args)
        + Unfortunately, CORBA relied on a very strong contract
          between client & server. There is no need to do this
          with D/BUS:
        ** extra arguments to functions, extra members in structures
           etc. should be silently elided / padded to 0 **
        + Of course there was interface versioning, and perhaps that
          is/was necessary but it never worked well.

    * Anonymous object references
        + In may applications there are no particularly obvious,
          or sensibly unique string names associated with objects
          we want to expose.
        ** There needs to be a good, performant, standard mangling
           for such objects. **

    * Introspection - performance
        + CORBA passes a type-id with every object reference.
          While that looks like wasteful overhead, it allows a
          remote client to realise that it is of an identical
          type to a previously introspected object - meaning
          that scripting bindings don't have to do 1 extra,
          synchronous round-trip per method call, plus a load
          of (XML?) parsing to be able to invoke a method on
          the object.
        ** D/BUS should do something similar, round-trips are
           expensive. **

    * Introspection - complexity
        + As previously discussed; there is a huge benefit to
          the existing 'getIntrospectionData' type method,
          however - the introduction of a new XML representation
          seems unnecessary.
                + that is particularly true if the base types
                  can be compatibly extended during marshalling.
        + this would avoid the need for an XML parser with
          commensurate time & space penalty, still provide
          equal extensibility, and reduce the representation
          count.
        ** D/BUS should use it's native type system to describe
           types instead of a foreign one **

    * Mapping recursive types to the native C ABI
        + This is a simple task - and we should be doing it to
          the GArray types - again, not a new idea.
        + Writing that code is _suprisingly_ complex, error
          prone, and difficult to test across the N architectures.
        + Re-licensing the ORBit2 code to do it should be no
          issue, it's mostly Novell/RH code.
        + ie. you should be able to call:
                sequence<GdkRectangle> getAreas(in long index);
          as: GArray *getAreas(glong index);
          and get not a GArray of GValue's or some ugly /
          cumbersome 'Any' type, but real struct GdkRectangles.

    * Flow control & blocking
        + It is often the case that two processes exist one
          producing events & one consuming them.
        + this situation requires careful handling to avoid
          the source out-producing the sink, leading to run-away
          memory consumption / failure.
        + this can either be performed by tiresome, complex &
          fragile user-land flow-control; or by the simple
          mechanism of blocking the socket to let the kernel
          deal with the issue.
        + unfortunately - most IPC channels are shared; if an
          out of control asynchronous event flow blocks a
          socket, then no - necessarily-under-control
          synchronous IPC can get down the same channel =>
          deadlock potential.
        + Thus it'd be nice to have the concept of a blockable
          event 'flow', vs. a point-to-point, reliable IPC
          channel.
        + A simple example is the flow of accessible events,
          each event often causing the sink to emit multiple
          round-trip calls to the source to fetch more
          information.

        I hope that helps, sorry it took so long.

        Regards,

                Michael.

--
 michael.meeks@...  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility

[Brian Cameron]

Rob/George:

The main reason for running with orbitrc configured with IPv4 turned on
is so that Java applications are accessible.  Since Java supports CORBA,
but does not support CORBA over a UNIX socket, it is necessary to
turn on IPv4 for Java programs to be accessible.  The LocalOnly
flag is then desirable to ensure that nobody from other machines
can use TCP/IP to connect to the ORBit server.

I'm not sure how Java a11y will work with D-Bus.  Is this in the
plan at all?

I'm a bit confused by the slowdown, though.  I thought that programs
that use UNIX sockets to connect to the ORBit2 server will continue to
do so even when TCP/IP is enabled.  My understanding was that enabling
TCP/IP with ORBit2 just made it possible for programs that want to use
TCP/IP to also be able to connect to the ORBit2 server (such as Java
programs).

Brian

> i.e. an orbitrc of
>
> OBITIIOPIPv4=1
> ORBLocalOnly=1
>
> is roughly 10% slower than
>
> ORBITIIOPUsock=1
>
> (on a linux system, in this case)
>
> We could test DBus over tcp (non-local) against ORBit over TCP
> (non-local), though I'm not sure how common a use-case this is.
>
> I'd expect that the numbers would get more similar between the dbus and
> orbit versus using unix sockets, as the time spent in transport would
> come to dominate. Message sizes are roughly similar between the two
> technologies and almost always would be under MTU.
>
> Thanks,
> Rob
>

_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility

[Rob Taylor-3]

Brian Cameron wrote:

>
> Rob/George:
>
> The main reason for running with orbitrc configured with IPv4 turned on
> is so that Java applications are accessible.  Since Java supports CORBA,
> but does not support CORBA over a UNIX socket, it is necessary to
> turn on IPv4 for Java programs to be accessible.  The LocalOnly
> flag is then desirable to ensure that nobody from other machines
> can use TCP/IP to connect to the ORBit server.
>
> I'm not sure how Java a11y will work with D-Bus.  Is this in the
> plan at all?

Supporting com.sun.java.accessibility shouldn't be hard, but we really
need with some input from people who understand how accessibility is
exposed by AWT/SWT/Swing..

> I'm a bit confused by the slowdown, though.  I thought that programs
> that use UNIX sockets to connect to the ORBit2 server will continue to
> do so even when TCP/IP is enabled.  My understanding was that enabling
> TCP/IP with ORBit2 just made it possible for programs that want to use
> TCP/IP to also be able to connect to the ORBit2 server (such as Java
> programs).

Well, the slowdown occurs when you disable local sockets, so no suprise
there :)

Thanks,
Rob

> Brian
>
>
>> i.e. an orbitrc of
>>
>> OBITIIOPIPv4=1
>> ORBLocalOnly=1
>>
>> is roughly 10% slower than
>>
>> ORBITIIOPUsock=1
>>
>> (on a linux system, in this case)
>>
>> We could test DBus over tcp (non-local) against ORBit over TCP
>> (non-local), though I'm not sure how common a use-case this is.
>>
>> I'd expect that the numbers would get more similar between the dbus and
>> orbit versus using unix sockets, as the time spent in transport would
>> come to dominate. Message sizes are roughly similar between the two
>> technologies and almost always would be under MTU.
>>
>> Thanks,
>> Rob
>>
>

--
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk
_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility

[Peter Korn-2]

Hi Rob,

Moving Java to a new IPC mechanism for accessibility will be work.  We
certainly have plenty of sample code to look at, and rolled our own
shared-memory-based IPC for Windows from Java, so it certainly can be
done (and the Windows side seems pretty fast, based on unscientific
performance analysis...).


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Brian Cameron wrote:
>  
>> Rob/George:
>>
>> The main reason for running with orbitrc configured with IPv4 turned on
>> is so that Java applications are accessible.  Since Java supports CORBA,
>> but does not support CORBA over a UNIX socket, it is necessary to
>> turn on IPv4 for Java programs to be accessible.  The LocalOnly
>> flag is then desirable to ensure that nobody from other machines
>> can use TCP/IP to connect to the ORBit server.
>>
>> I'm not sure how Java a11y will work with D-Bus.  Is this in the
>> plan at all?
>>    
>
> Supporting com.sun.java.accessibility shouldn't be hard, but we really
> need with some input from people who understand how accessibility is
> exposed by AWT/SWT/Swing..
>
>  
>> I'm a bit confused by the slowdown, though.  I thought that programs
>> that use UNIX sockets to connect to the ORBit2 server will continue to
>> do so even when TCP/IP is enabled.  My understanding was that enabling
>> TCP/IP with ORBit2 just made it possible for programs that want to use
>> TCP/IP to also be able to connect to the ORBit2 server (such as Java
>> programs).
>>    
>
> Well, the slowdown occurs when you disable local sockets, so no suprise
> there :)
>
> Thanks,
> Rob
>
>  
>> Brian
>>
>>
>>    
>>> i.e. an orbitrc of
>>>
>>> OBITIIOPIPv4=1
>>> ORBLocalOnly=1
>>>
>>> is roughly 10% slower than
>>>
>>> ORBITIIOPUsock=1
>>>
>>> (on a linux system, in this case)
>>>
>>> We could test DBus over tcp (non-local) against ORBit over TCP
>>> (non-local), though I'm not sure how common a use-case this is.
>>>
>>> I'd expect that the numbers would get more similar between the dbus and
>>> orbit versus using unix sockets, as the time spent in transport would
>>> come to dominate. Message sizes are roughly similar between the two
>>> technologies and almost always would be under MTU.
>>>
>>> Thanks,
>>> Rob
>>>
>>>      
>
>
>  

_______________________________________________
kde-accessibility mailing list
kde-accessibility@...
https://mail.kde.org/mailman/listinfo/kde-accessibility