W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2000

Re: Suggested note to Checkpoint 5.5 on timeliness

From: mark novak <menovak@facstaff.wisc.edu>
Date: Tue, 7 Mar 2000 16:46:39 -0600
Message-Id: <v01540b10b4eb35792bcd@[128.104.23.196]>
To: schwer@us.ibm.com, "Hans Riesebos" <HRiesebos@alva-bv.nl>
Cc: jongund@ux1.cso.uiuc.edu, "<" <w3c-wai-ua@w3.org>
hi Rich and Hans

interesting how this discussion has come full circle from when
Rich and I originally wrote several of the current techniques.


<PROPOSEDRICH>
<snip>

>>One effective technique
>>for providing timely access is to allow assistive technologies to run
>>in the same process space as the user agent, thus eliminating
>>inter-application communication delays.

>></PROPOSEDRICH>

>Shouldn't we have techniques in the techniques document?
</snip>

I still agree with Hans and others, the "how to" do this is a technique
and thus whether we say in-process, out-of-process, java bridge, etc.,
they all belong in the techniques doc.,  not as part of the guidelines document.


mark


At 3:41 PM 3/7/00, schwer@us.ibm.com wrote:
>Hans,
>
>First, you don't architect your solution to have the entire AT software
>package run in process with the application. You have only the portions
>necessary to improve performance run in process with the application. We
>did this very successfully in Screen Reader/2 when supporting Windows. If
>you were to use the Java access bridge or the SVK to help support Java
>appications you are successful also. Much of what you need can run in
>process and if the Java app dies you only lose the part of the AT dealing
>with that application which is dead anyway.
>
>Also, if the main AT goes down the the part running in the UA should not go
>down.
>
>Given current technologies, in particular OSM it is extremely easy to not
>only bring the application down but the entire system. Since ultimately the
>OSM will run in process for all applications by virtue of the fact that it
>is a DLL linked in the graphics call chain of the application. So, there is
>nothing new that in-proces introduces that is not already an issue today
>for other AT mechanisms for getting at information.
>
>Your downside concerns are not warranted.
>
>Rich
>
>Rich Schwerdtfeger
>Lead Architect, IBM Special Needs Systems
>EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm
>
>"Two roads diverged in a wood, and I -
>I took the one less traveled by, and that has made all the difference.",
>Frost
>
>
>"Hans Riesebos" <HRiesebos@alva-bv.nl> on 03/07/2000 11:21:05 AM
>
>To:   jongund@ux1.cso.uiuc.edu
>cc:   "<" <w3c-wai-ua@w3.org>
>Subject:  Re: Suggested note to Checkpoint 5.5 on timeliness
>
>
>
>
>Rich wrote:
>
><PROPOSEDRICH>
>>This checkpoint is designed to reduce delays that an assistive
>>technology user might experience due to communication overhead when
>>accessing
>>parts of your application such as your DOM.
>>Timely exchange is import for preventing loss of information,
>>a risk when changes in content occur faster than the
>>exchange with the assistive technology. One effective technique
>>for providing timely access is to allow assistive technologies to run
>>in the same process space as the user agent, thus eliminating
>>inter-application communication delays.
>></PROPOSEDRICH>
>>
>
>I'm really sorry that I only bring this "in process" argument to attention
>now. I understood that the mention of "in process" would never make it to
>the checkpoint-text (or notes with it).
>
>Shouldn't we have techniques in the techniques document?
>
>The argument:
>
>"In process"  IS an effective technique. It has an important downside. If
>the AT crashes "in process" it crashes the UA. The AT can also have the UA
>crash by (inadvertently?) corrupt internal data of the UA. I am (almost)
>sure this is not what a UA is willing to do.
>
>A way to a solution?
>
>The "in process" technique leads to three performance improvements:
>1) No process switching needed
>2) No waiting until the next process switch is needed
>3) No copying of data needed (reaching other process's memory is not
>possible on Win32 platforms. I am not sure but I believe it is possible on
>the Macintosh)
>
>Point 3 can be solved by using shared memory (is a technique). I am aware
>that shared memory can be corrupted when it is writable.
>
>Point 2 can be solved by giving higher (or equal?) priority to the
>AT-process-threads or explicitly allowing a switch by the UA. I am aware
>that the AT could starve the UA.
>
>Point 1 can ONLY be solved by going "in process". It has the disadvantages
>of data corruption AND the AT taking all the CPU time AND corruption of
>internal UA-data.
>
>Bottom-line.
>In process is a technique that has great efficiency and a big downside. I
>personally think the downside is too big to even recommend this technique.
>It still is a technique and should (if mentioned) be mentioned in the
>techniques document.
>
>sincerely, Hans Riesebos
>ALVA, The Netherlands
>HRiesebos@alva-bv.nl
>
>>>> Jon Gunderson <jongund@ux1.cso.uiuc.edu> 03/06/00 06:22PM >>>
>Hans,
>
>1. Would a clause that said:
>
>"One effective technique in operating sytems that use separate process
>spaces for providing timely access is to allow assistive technologies to
>run in the same process space as the user agent, thus eliminating
>inter-application communication delays"
>
>2. Do you have any examples of what techniques would be useful on a
>Macintosh operating system to support inter-process communication?
>
>Thanks,
>Jon
>
>
>At 05:35 PM 3/6/00 +0100, Hans Riesebos wrote:
>>I think that the "In process" must not be mentioned or at best be
>mentioned
>>in the techniques document (not in the guidelines).
>>Letting an AT in process is a potential security hole! Also, for the
>>Macintosh, there are no seperate process-spaces and therefore is in
>process
>>less meaningful.
>>
>>>>> Jon Gunderson <jongund@ux1.cso.uiuc.edu> 03/03/00 04:44PM >>>
>>Note to checkpoint 5.5: This checkpoint is designed to promote the use of
>>APIs which provide efficient exchange of information between user agents
>>and assistive technologies.  Notably in multi-tasking operating systems
>>this requires the ability to access the DOM and other Accessibility APIs
>in
>>process.  In process communication eliminates the time delays which occur
>>with out-of-process communication between applications.  The time delays
>>can result in slower response to user actions or potentially the user
>>missing important information.
>>
>>Jon
>>
>>Jon Gunderson, Ph.D., ATP
>>Coordinator of Assistive Communication and Information Technology
>>Chair, W3C WAI User Agent Working Group
>>Division of Rehabilitation - Education Services
>>College of Applied Life Studies
>>University of Illinois at Urbana/Champaign
>>1207 S. Oak Street, Champaign, IL  61820
>>
>>Voice: (217) 244-5870
>>Fax: (217) 333-0248
>>
>>E-mail: jongund@uiuc.edu
>>
>>WWW: http://www.staff.uiuc.edu/~jongund
>>WWW: http://www.w3.org/wai/ua
>>
>>
>
>Jon Gunderson, Ph.D., ATP
>Coordinator of Assistive Communication and Information Technology
>Chair, W3C WAI User Agent Working Group
>Division of Rehabilitation - Education Services
>College of Applied Life Studies
>University of Illinois at Urbana/Champaign
>1207 S. Oak Street, Champaign, IL  61820
>
>Voice: (217) 244-5870
>Fax: (217) 333-0248
>
>E-mail: jongund@uiuc.edu
>
>WWW: http://www.staff.uiuc.edu/~jongund
>WWW: http://www.w3.org/wai/ua
Received on Tuesday, 7 March 2000 17:43:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:52 GMT