Re: [g-a-devel] [Kde-accessibility] [Accessibility] Re: [Accessibility-atspi] D-Bus AT-SPI - The way forward




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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]