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

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> 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.
>
>
>