Re: D-Bus AT-SPI - The way forward

> 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-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

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-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

[ 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-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

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-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

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-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

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-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

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-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

On Mon, 2007-12-10 at 21:57 +0000, Rob Taylor wrote:
> 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..

	Surely there should not be a per-toolkit wrt. simply
bridging to a
different IPC mechanism. And indeed, the plus for Java of
course would
be that it should be faster than using TCP sockets, more
secure, and (of
course) will work on stock Linux systems (that disable
IPv4/6 sockets).

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

	I'd also expect a (small) slowdown just enabling IPv4
sockets, whether
they are used or not (and they're not preferred clearly),
since in
itself that ~doubles the size of each object profile we
marshal.

	HTH,

		Michael.

-- 
 michael.meeksnovell.com  <><, Pseudo Engineer,
itinerant idiot


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

Michael Meeks wrote:
> On Mon, 2007-12-10 at 21:57 +0000, Rob Taylor wrote:
>> 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..
> 
> 	Surely there should not be a per-toolkit wrt. simply
bridging to a
> different IPC mechanism. And indeed, the plus for Java
of course would
> be that it should be faster than using TCP sockets,
more secure, and (of
> course) will work on stock Linux systems (that disable
IPv4/6 sockets).

I think I could definitly do with a bit more of a background
on how java
toolkits expose themselves. Could you quickly go though what
components
do which bits and how corba currently ties in?

>>> 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 
> 
> 	I'd also expect a (small) slowdown just enabling IPv4
sockets, whether
> they are used or not (and they're not preferred
clearly), since in
> itself that ~doubles the size of each object profile we
marshal.

Actually we did seem see that, but it was small enough a
difference  (~
5%) that it could have been noise.

Rob
> 	HTH,
> 
> 		Michael.
> 


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

Hi Rob:

Though I helped create the Java accessibility API proper,
I'm not quite 
sure how the CORBA stuff is handled.  I've only worked on a
few bugs in 
the java-access-bridge (see 
htt
p://svn.gnome.org/svn/java-access-bridge/trunk), it's
still a slight 
bit beyond me.

It's probably obvious, but the main code seems to live in
these 
directories.  The one I play in the most is the 'impl' one:

http://svn.gnome.org/svn/java-a
ccess-bridge/trunk/bridge/org/GNOME/Accessibility/
http://svn.gnome.org/svn/java-acc
ess-bridge/trunk/impl/org/GNOME/Accessibility/
http://svn.gnome.org/svn/java
-access-bridge/trunk/registry/org/GNOME/Accessibility/

As part of the build, I believe an idlgen pass is done that
creates all 
the stub/skeleton stuff that lives under the idlgen
directory.  I'm 
going to be digging a bit more in there this week, so I hope
to learn more.

Will

Rob Taylor wrote:
> Michael Meeks wrote:
>> On Mon, 2007-12-10 at 21:57 +0000, Rob Taylor
wrote:
>>> 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..
>> 	Surely there should not be a per-toolkit wrt.
simply bridging to a
>> different IPC mechanism. And indeed, the plus for
Java of course would
>> be that it should be faster than using TCP sockets,
more secure, and (of
>> course) will work on stock Linux systems (that
disable IPv4/6 sockets).
> 
> I think I could definitly do with a bit more of a
background on how java
> toolkits expose themselves. Could you quickly go though
what components
> do which bits and how corba currently ties in?
> 
>>>> 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 
>> 	I'd also expect a (small) slowdown just enabling
IPv4 sockets, whether
>> they are used or not (and they're not preferred
clearly), since in
>> itself that ~doubles the size of each object
profile we marshal.
> 
> Actually we did seem see that, but it was small enough
a difference  (~
> 5%) that it could have been noise.
> 
> Rob
>> 	HTH,
>>
>> 		Michael.
>>
> 
> 

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