Separate interface for controlling page and presenting page about presentation-api

[anssiko]

@schien Thanks for the concrete proposal.

All - @tidoust has a nice explanation in the Conformance classes definition issue why this separation makes very much sense. Please read the issue, and let the group know if you have any concerns with separating the interfaces to reflect the two conformance classes of products as follows (naming subject to change): opening user agent (or controlling user agent to align with #95) and presenting user agent. This issue proposes the first concrete change to implement this separation.

@mfoltzgoogle How would you like to proceed with baking this into the spec? I suggest you coordinate with @schien who volunteered to help.

[mfoltzgoogle]

I think I would like to define the conformance classes for the controlling/opening browsing context and the presenting browsing context as in #93 and re-outline the document as best as I can along those lines.

Then it will be easier to introduce the new interfaces proposed by @schien since they will have a logical place in the new document.

[avayvod]

A naming idea:
navigator.present - for the controller (sender) page
navigator.presentation - for the presentation (receiver) page

So we leave what we have for the presentation where it is and move the sender API to the shorter interface.

[anssiko]

It seems no concerns raised with the general direction proposed by @schien. It also appears we've not yet settled on the interface naming. We should first update the Conformance section using the @tidoust's proposal as a starting point and bake in the changes to the normative parts when consensus emerges on naming.

All - please let us know your preference and/or suggestions with respect to naming.

@mfoltzgoogle Feel free to update the Conformance section with a note stating that the rest of the spec have not yet been reworked to match the conformance classes split.

[mounirlamouri]

@schien what do you think of:

interface Presentation {
  attribute PresentationSession? defaultRequest;
  readonly attribute PresentationReceiver? receiver;
};

interface PresentationReceiver : EventTarget {
  Promise<PresentationSession> getSession();
  Promise<sequence<PresentationSession>> getSessions();
  attribute EventHandler onsessionavailable;
};

I think it has the benefit of splitting the receiver and sender APIs and also provide a good way to find out whether the current browsing context is a receiver (ie. navigator.presentation.receiver is not null).

[schien]

Overall looks good to me, but I still prefer PresentingContext over PresentationReceiver. It's more consistent to the common idiom we defined in spec.

[mounirlamouri]

I think PresentingContext has multiple downsides:

• navigator.presentingContext isn't in the navigator.presentation namespace
• PresentingContext isn't prefixed with Presentation
• I think navigator.presentation.receiver is clearer about what it does compared to navigator.presentingContext.

[mounirlamouri]

@sicking, an opinion?

[sicking]

I'm fine with any of the proposals here, but I'd probably go with @mounirlamouri's proposal if I had to choose.

[tidoust]

I like the idea of sticking to the navigator.presentation namespace.

That's more an editorial point perhaps but since we'll end up with two conformance classes in the spec, it seems good to have separate IDL for each class of products to be able to say "the controlling user agent MUST implement the interface defined in section X.Y." instead of "the controlling user agent MUST implement the defaultRequest attribute of the Presentation interface".

How would you define the resulting Presentation interface in the spec, @mounirlamouri ? An empty interface completed with two partial interfaces, one with defaultRequest and the other with receiver?

[mounirlamouri]

We can't really have two partial interfaces because we need a Presentation interface which would be null. I will go with one Presentation interface with both objects unless there is an objection.

[anssiko]

@mounirlamouri Please submit a PR with your proposal. It is probably easier for the participants to review the changes in context. I suggest you update the conformance section to match in the same PR (you can borrow the language from #93) and cross-reference the conformance classes appropriately.

As long as the spec is clear to implementers (what must be implemented/tested) and authors (albeit there are surely better API docs for web developers than specs) on the division, we should be fine with @mounirlamouri's proposal even if the spec would end up being a bit more verbose that way. The extra editorial cost will pay off.

[mounirlamouri]

FWIW, the PR is up and was sent between my previous comment and yours. It should show up in GH UI. For those who interact on issues via email, it is issue #186.