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

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