- it would allow the client to live in WebCore. FWIW, Geolocation seems to take both approaches. One implementation is down in Navigator/Document/DOMWindow, but the mock controller is on Page. I've found the low-level approach much easier to implement. My understanding was that clients for these platform-specific features should live in the WebKit layer. The original Geolocation implementation used a platform-specific GeolocationService in WebCore, but a client-based implementation was later added by Sam to avoid the layering violations of the former approach. See https://bugs.webkit.org/show_bug.cgi?id=32499#c10.
I'm currently working to remove the old non-client-based Geolocation implementation, see https://bugs.webkit.org/show_bug.cgi?id=40373. Please let me know if this is the wrong approach!
I assume one of the advantages of having them on Page is that it allows a Mock Controller to be easily created for testing from Dump Render Tree. Am I right? Is this that important? Yes, that is also part of the motivation. The non-client-based Geolocation implementation provides a mock in WebCore, but setting and configuring this mock from DumpRenderTree is ugly.
For this sort of thing, it seems reasonable to me that there is a layer of the implementation that is a per-document controller, and then below that a singleton object in case we don't need things to happen multiple times per document. I don't have a strong opinion regarding Page vs Document, but it seems that other platform-specific clients of this type belong to the Page. I agree that it's likely that a platform will use a singleton at the lowest level, but the platform can provide the multiplexing whether the client is provided to the Page or the Document.
Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902