In verifying this checkpoint it is difficult to know how to interpret
"timely". Is there a way we can better describe the user need, and therefore
improve the verification?
As Mark suggests, describing the techniques that can be used (on one
platform, for one kind of User Agent!!) is not sufficient for a checkpoint. I
think there is a user need that this timeliness requirement satisfies, and I
think we need to make it a lot clearer what that is.
Charles McCN
Charles McCN
>5) Discussion of techniques for checkpoint 5.5 Ensure that programmatic
> exchanges proceed in a timely manner.
>
> JG: Out of discussions with Charles at Microsoft. Question of
> how to verify timeliness.
>
> Checkpoint 5.5 in Candidate Rec [2].
> [2] http://www.w3.org/TR/2000/CR-UAAG10-20000128
>
> IJ: What does "timely" mean?
>
> JG: What do we mean by this checkpoint?
>
> RS: Where this originated - in Windows, they want you to use the
> COM. Since you can only do this from another process, you are
> affected by system scheduling priorities. Access is then slow.
> We found in tests that in-process response times were 12 times
> faster.
MN: Please refer to the Tech DOC., COM is *not* limited to
out-of-process only. The Browser Helper Object (BHO) is an
in process DLL, which uses COM to communicate and interact
with IE in a very fast manner. It does not suffer any system
scheduling problems when run in this manner.
>
> DA: The AT user should have the same experience.
>
> RS: Want no noticeable degradation in performance.
>
> DA: In Word 97 (Win98), virtual keyboard input much slower than
> physical keyboard input.
MN: Without invertigating the methods used, I'm not sure you
can make any conclusions based on this. For example, injecting
keyboard information at the device driver level using a virtual device
driver in Windows (Vxd) can be much slower than injecting
keyboard information using the Win32 keyboard API. It
also could just be poorly written code.
> JG: So "timely" has do to with process scheduling.
>
> JG: The other issue is synchronization.
>
> RS: You can't assume synchronization with fast APIs.
> Suppose that while the AT is traversing the DOM tree,
> if the location in memory is deleted, or the element
> members are distorted, accessing those memory locations
> could lead to a crash. This is a separate issue.
>
> DP: An example of timeliness: an AT starts rendering *before*
> a new page is loaded.
>
> DA: That's part of the proposed handshaking technique.
>
> JG: Apparently you can't start traversing the tree
> until the load complete event received.
>
> JG: Is timeliness separate from the synch issue?
>
> RS: I don't think the two should be mixed.
> Some locking mechanisms may be necessary to prevent
> corruption, etc.
>
> JG: Glen Gordon has complained about the MS because of out-of-process
> access. They developed their own since they could do so in
> process.
>
> RS: Semaphore interface necessary when running on a separate thread.
> That may be part of a WAI PF requirement for DOM 3.
>
> GR: I had proposed a checkpoint based on a WAI PF discussion.
> I'll post the proposal to the PF list as part of our DOM 3
> wish list.
>
> IJ: I don't think it's reasonable to require a semaphore interface
> on user agents.
>
> /* Return to verification of "timeliness" in 5.5 */
>
> DB: I should consult Rob Sinclair (at MS, does MSAA) on this.
>
> RS: I've sent email to him.
>
> RS: The "helper" facility from IE is one technique for being
> in-process. Another is to embed the browser in your application.
MN: yes and yes
>
> RS: I'd like to see "in-process" happen. It would take significant
> changes to MSAA to make that happen.
MN: I'm not following this statement at all. Using a BHO, I have
access to all the information in IE's DOM. Where does MSAA play
a role?
> IJ: I think that if in-process is required, the problem of
> no standard for access to the DOM falls away.
>
> IJ: I propose asking PF two questions:
> - Should we change "timely" to "in-process"?
> - What kind of synchronization necessary?
MN: I think the issue of "in-process", "out-of-process", etc., is beyond
the scope of the UA group. All the methods ought to be listed, as in the
Tech. DOC., and it is up to the AT developers to decide what works
best for their product/market.
MN: I realize the UA group is trying to define "timely", and that is
why I suggested developing a reference prototype/platform about
two weeks ago.
>
> Need feedback by 18 Feb.
>