Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing the Platform Bindings to Combination Bindings #226

Open
egekorkan opened this issue Jan 25, 2023 · 7 comments
Open

Changing the Platform Bindings to Combination Bindings #226

egekorkan opened this issue Jan 25, 2023 · 7 comments

Comments

@egekorkan
Copy link
Contributor

This is mostly editorial at this point given that there are no Platform Bindings but I had struggled before to find a name for cases like ECHONET Lite Web API, Philips Hue, and similar. Some of them are product ecosystems, some are platforms and some are standards that are about the protocol and data format. I think the word "Platform" is misleading given that ECHONET Lite Web API is not really a platform from my understanding. So I would propose changing the name of the category to "Combination Bindings" . It is not an "elegant" name but would make things more clear.

@egekorkan
Copy link
Contributor Author

I have also used this term in the new charter proposal (line 278 at https://github.com/w3c/wot/pull/1065/files#diff-c932dc2c3feab042e31ac1654200765dee2318c17286329a1defd6195969e3d3R278)

@JKRhb
Copy link
Member

JKRhb commented Jan 26, 2023

Hmm, could "ecosystem binding" be an alternative? This could cover platforms, subprotocols, and APIs at the same time.

@egekorkan
Copy link
Contributor Author

After talking with @mjkoster , another proposal would be to call them a "Framework Binding"

@benfrancis
Copy link
Member

some are standards that are about the protocol and data format

Another use case I've been thinking about is Server-Sent Events, where I'm not sure it really makes sense to specify a "Server-Sent Events Protocol Binding" and "Event Stream Payload Binding" (for the text/event-stream content type) separately.

Whilst in theory it's possible to use the Server-Sent Events "protocol" with other event framing formats, in practice the two are tightly coupled together and are defined in the same section of the same WHATWG specification.

@egekorkan
Copy link
Contributor Author

Call of 05.04:

  • @mmccool : Arch spec uses platform at terminology. Framework is neutral and sounds good.

  • @ashimura : Confusing to say that there are three bindings types, there is one mechanism.

  • @mmccool : Each binding could say what part of TD it constrains

  • @ashimura : we should get more information on what developers expect and best practices

  • The participants of the call are tending towards removing the distinction and call documents like "HTTP Binding", "JSON Binding" and "OPCUA Binding" and the documents can specify what they "bind" and constrain.

@chachamimm
Copy link

I agree @ashimura opinions.

This is my opinion.

I don't think the protocol binding naming issue is too important.

If you want to change the name of the binding template, you should analyze and define and categorize all IoT protocols and IoT functions before renaming. If you can't define and categorize, naming issues will cause to confuse. Because people have different points of view.

I think "the platform bindings", "the combination bindings" are results.

I think we need to think about the core binding template. I think "HTTP Binding", "JSON Binding" and "OPCUA Binding" are results to adapt the core binging template.

ECHONET Lite Web API has already been implemented WoT. So I don't know if it is correct to deal with ECHONET Lite Web API in the binding template.

@egekorkan
Copy link
Contributor Author

See #281 for further discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants