Re: should profiles be a separate, optional, section in capabilities

I agree with that word-smithing I think. The intent is not to force the 
need to expose the ability to use multiple profiles, but if they do, to 
lock them into a standardized means of transmitting them over the wire.

'If a WebDriver implementation has runtime configurable profiles, the 
implementation can support configuration of them as a Capability.' as 
the preamble, then the example and the 'must' can remain untouched.

-adam

> Hi,
>
> While I appreciate the goal, I'm uncertain whether "must" is the right 
> word: I can think of good reasons why a browser might technically 
> support multiple profiles, but the vendor be unwilling to expose that 
> capability (eg: JellyBean on tablets supports multiple accounts, 
> whereas on phones it doesn't though I strongly suspect that there's a 
> vast amount of shared code there. An AndroidDriver would probably want 
> to support profiles on a tablet but not on a phone)
>
> I'd be happy to add "should" style language, though and move it out of 
> a sidebar.
>
> Simon
>
>
> On Mon, Nov 26, 2012 at 7:41 AM, Adam Goucher <adam@goucher.ca 
> <mailto:adam@goucher.ca>> wrote:
>
>     Having gone through the SAML and ID-FF spec process, I am a bit
>     worried about the fuzzy language around profiles in the spec which
>     gives implementers a choice about how things are sent over the
>     wire. (And its inclusion as what looks like a sidebar.)
>
>     I would be much happier if Profiles was its own separate section.
>     Sure, only Opera and Firefox implement runtime-configurable
>     profiles (at present) which means it would likely look something
>     like below which removes instances of 'should' and provides
>     something more concrete for future implementers to reference.
>
>     -adam
>
>     3.3. Profiles
>
>     If a WebDriver implementation has runtime configurable profiles,
>     the implementation must support configuration of them as a
>     Capability. This may be modelled in code as a "Profile" object,
>     leading to code such as:
>
>             profile = Profile("some/user/directory")
>             capabilities = MutableCapabilities()
>             capabilities.set('profile', profile)
>             driver = RemoteDriver(capabilities)
>
>     In this example, the profile represents a directory on the local
>     disk. The contents of this directory must be serialized as a
>     base64 encoded zip file to allow it to be passed as a string.
>
>
>