> (1) Adds a level of indirection that may not be necessary in these cases. It's true, there's now one more level of indirection. The non-client-based implementation uses Geolocation -> GeolocationServiceFoo. The client-based implementation uses Geolocation -> GeolocationController -> GeolocationServiceFoo. I don't think this is significant, especially as the Controller/Client pattern is well established.
> (2) Harder to find the back end code, since the common pattern is to have > platform-specific > implementations in WebCore/platform True, though as I mentioned previously, I'm not sure that Geolocation really fits into the category of 'platform-specific implementations' - there are too many decisions to be made by the embedder. > (3) There may not be a one-to-one mapping between back-end implementations > and WebKit public > APIs. So far, there is a one-to-one mapping. My argument is that this likely to remain the case because embedders want to have close control over their Geolocation implementation (for example, when to enable a GPS if present, which URL to use for network-based lookups, how to handle position caching, how frequently to poll for updates etc). While it might be possible to have a GeolocationServiceLinux in WebCore/platform/linux, for example, that would provide position information for all Linux-based ports, I think that in practice, the embedder wants to have more control than this approach permits. So I think there will be little, if any code duplication between ports. If we later find that multiple ports are duplicating code by using a common platform library, for example, we could consider adding a shared WebCore utility to provide access to this. > So that explains the upsides, but you didn't address the downsides I cited. Sorry, I hope I've done so now. > Maybe the positives outweigh the negatives, Yes, that's exactly my opinion. Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
