- From: mark novak <menovak@facstaff.wisc.edu>
- Date: Tue, 7 Mar 2000 16:46:39 -0600
- 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 UTC