Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
FlyWeb looks like another UPnP?
90 views
Skip to first unread message
Thinker K.F. Li
Dec 25, 2015, 4:18:04 AM12/25/15
to dev-f...@lists.mozilla.org
My first time to know Flyweb is at Mozlando. I don't know it very well.
With my limited knowledge of flyweb and UPnP, I think they are very
similar.
I had worked on UPnP devices about 10 years ago. Most people may not
know that UPnP also defined the way for presentation. [1] It is also WEB
based. The basic idea is that an optional URL for UI goes along the
advertisement of a service or device. The page specified by the URL is
a user interface provided by the service or device. User can open it
with a web browser to view the page to control the device or to use the
service provided by the service.
I just browser through the draft of flyweb. I am not sure if I have
missed anything. If I am right, may be we should look at the solution
defined by UPnP.
[1] https://en.wikipedia.org/wiki/Universal_Plug_and_Play#Presentation
--
Sinker
--
天教懶漫帶疏狂
With my limited knowledge of flyweb and UPnP, I think they are very
similar.
I had worked on UPnP devices about 10 years ago. Most people may not
know that UPnP also defined the way for presentation. [1] It is also WEB
based. The basic idea is that an optional URL for UI goes along the
advertisement of a service or device. The page specified by the URL is
a user interface provided by the service or device. User can open it
with a web browser to view the page to control the device or to use the
service provided by the service.
I just browser through the draft of flyweb. I am not sure if I have
missed anything. If I am right, may be we should look at the solution
defined by UPnP.
[1] https://en.wikipedia.org/wiki/Universal_Plug_and_Play#Presentation
--
Sinker
--
天教懶漫帶疏狂
kvij...@mozilla.com
Jan 11, 2016, 4:14:29 PM1/11/16
to mozilla-d...@lists.mozilla.org
Hey, sorry for the late reply. I turns out I wasn't actually subscribed to the list. I saw this question got referred to in b2g-internal.
The core flyweb initiative tries to take a look at the full-stack problem of using browsers to discover and consume services. A number of existing standards fill in pieces of that story, but there are many details missing.
UPNP has a discovery spec (which could be used by flyweb as an underlying discovery protocol), as well as schema definitions for HTTP-based local-area service profiles (lights, devices, home entertainment, etc.).
The discovery spec is fine. It's a different approach to the same discovery functionality provided by Bonjour/Zeroconf/DNS-SD+mDNS, but ultimately provides the same benefits.
These protocols, however, don't cover all the semantic requirements we expect to run HTTP sessions, though. Let's say you get a "http://FOO.local/" URL for a service named FOO. Does the browser send cookies stored from the last interaction with "FOO.local"? How can it know that this new service is the same as the last one with the same name?
Like the above, there are a number of semantics that need to be specified and standardized in an implementation. Part of that specification will be underlying discovery protocols, and transport mechanisms (e.g. bluetooth) - to enable a "web session" to operate in a local-area discovery-based environment.
I see UPNP, DNS-SD, and other interop standards as existing general components. To utilize them well, they need to be embedded within a larger specification for the extra pieces needed for web sessions to work - e.g. certificate-based identity, advertising a rich badge instead of just a name, mechanisms for establishing device identity, abstracting over non-TCP transport protocols etc.
The core flyweb initiative tries to take a look at the full-stack problem of using browsers to discover and consume services. A number of existing standards fill in pieces of that story, but there are many details missing.
UPNP has a discovery spec (which could be used by flyweb as an underlying discovery protocol), as well as schema definitions for HTTP-based local-area service profiles (lights, devices, home entertainment, etc.).
The discovery spec is fine. It's a different approach to the same discovery functionality provided by Bonjour/Zeroconf/DNS-SD+mDNS, but ultimately provides the same benefits.
These protocols, however, don't cover all the semantic requirements we expect to run HTTP sessions, though. Let's say you get a "http://FOO.local/" URL for a service named FOO. Does the browser send cookies stored from the last interaction with "FOO.local"? How can it know that this new service is the same as the last one with the same name?
Like the above, there are a number of semantics that need to be specified and standardized in an implementation. Part of that specification will be underlying discovery protocols, and transport mechanisms (e.g. bluetooth) - to enable a "web session" to operate in a local-area discovery-based environment.
I see UPNP, DNS-SD, and other interop standards as existing general components. To utilize them well, they need to be embedded within a larger specification for the extra pieces needed for web sessions to work - e.g. certificate-based identity, advertising a rich badge instead of just a name, mechanisms for establishing device identity, abstracting over non-TCP transport protocols etc.
0 new messages