Re: [WebDriver] getPageSource - Does it need to be a remote end call?

On 10/04/15 12:12, Andreas Tolfsen wrote:

>> If otherwise it is beyond the authority/outside of the scope, then I think keeping the remote end endpoint would help insure the functionality is preserved. (still more specification than "artist's impression" would help)
> 
> Yes, I think if it's a mobile requirement I have no problem leaving this in the spec.

It isn't in the spec at the moment, and I object to adding it at this point:

1) It's an entirely backwards-compatible change so can be added at any
time in the future.

2) We have *very* limited editing resources and plenty of work to do on
the things that are already part of the spec

3) It's trivial to implement in clients in a way that covers all the use
cases for the current spec (i.e. interacting with web browsers).

4) We have a limited time before the WG charter expires, and not having
either a published spec, or something that looks credibly like it is
about to become one is not going to go down well.

In particular I think that the questions corresponding to 1) and 3);
i.e. "is this possible to add later in a backwards compatible way" and
"is this trivial to implement in clients" should be used as *the*
criteria to determine whether a feature is considered for inclusion at
the current time.

On the other hand, if someone wanted to write a *non-normative* appendix
covering common / expected client side features in existing WebDriver
implementations, that would be OK, although I still question the value
somewhat. There's no requirement that client APIs are mutually
compatible, and the only constraint that they put on this spec is that
it contains the features required to implement the clients that people
want to write. In the case of getPageSoure it's clear that clients which
already have it aren't going to drop it, and that there's an obvious way
to implement in the existing protocol.

Received on Friday, 10 April 2015 12:24:12 UTC