Re: Local Discovery addendum update for mDNS

I quite like the idea a lot of web developers are used to managing DNS for
verification of ownership of Google Apps accounts and Web Master tools (you
encode a TXT record with the information).  That being said, it can be a
little be daunting, problems with propegations and a nightmare to configure
depending on provider.

Another point, I have spoken to several large retail companies in the past
and changing DNS is a larger task from an Operations PoV than changing a
template for a page (and in a lot of cases deploying a new file is pretty
hard - too much work) etc.

Would the suggested Scope be:

   - UPnP- home and local discovery
   - mDNS etc - web discovery, centrally managed by owner
   - intent tag (or other) - web discovery, developer experience/ease of
   starting

P



On Mon, Jul 30, 2012 at 4:41 AM, James Hawkins <jhawkins@google.com> wrote:

> This seems like an interesting idea, especially as a supplement to the
> existing registration mechanism(s).  My initial thought is that this seems
> a bit daunting for the average web developer, but I suppose it's not geared
> at that crowd.
>
> My second thought is that it may add unnecessary complexity to the API.
>  We should definitely attempt to figure out how open folks are to investing
> in the cost necessary to support this registration, as it moves outside of
> the realm of the abilities of Joe WebDev.
>
> Thanks,
> James
>
>
> On Fri, Jul 27, 2012 at 7:32 AM, Rich Tibbett <richt@opera.com> wrote:
>
>> Norifumi Kikkawa wrote:
>>
>>> Claes and I updated the addendum to support mDNS.
>>>
>>> http://w3c-test.org/dap/wi-**addendum-local-services/<http://w3c-test.org/dap/wi-addendum-local-services/>
>>>
>>> The basic idea is same as that for UPnP. The discovery protocol is used
>>> to obtain the location of the WebIntents page.
>>>
>>
>> I haven't gone through the proposal in detail just yet but my
>> understanding at this point is that it essentially provides a way to
>> bootstrap the registration of standard Web Intents Providers via common
>> discovery protocols (mDNS/DNS-SD and SSDP).
>>
>> As I mentioned at the F2F a couple of weeks ago I think that there is a
>> big opportunity here to re-use the mDNS/DNS-SD parts of this spec to be
>> able to bootstrap the registration of Web Intents providers from wide-area
>> networks i.e. the web.
>>
>> The UA (though probably not individual web pages) could query the root
>> DNS record of e.g. 'google.com' (by setting the mDNS search domain to '.
>> google.com') and then register any and all web intent services that are
>> included therein automatically in the UA.
>>
>> It means that as a user navigates different domains on the web the UA
>> itself could simultaneously and orthogonally make a query for Web Intent
>> service records included in that domain's root DNS record (according to the
>> format defined in this spec) and register those Web Intents in the UA for
>> future invocation by any web pages.
>>
>> It would be an alternative (bootstrap) mechanism for registering web
>> intent providers and it could be complimentary to both the programmatic and
>> declarative way to register Web Intents that we have now. In some ways it
>> may be even cleaner than the other registration methods since there is only
>> ever one single authorative record of the Web Intents that any given domain
>> provides (in the domain's root DNS record). That avoids the issue of
>> different web pages on the same domain potentially contradicting each other
>> wrt the Web Intent Providers available on the domain.
>>
>> I'm wondering if it's worth discussing this further here, if you have had
>> any thoughts in this general direction and if it's something we might want
>> to cover in this specification or elsewhere.
>>
>> Would be good to get input on having this type of bootstrap registration
>> process for Web Intents.
>>
>> br/ Rich
>>
>>
>


-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
Watch my I/O talk: http://www.youtube.com/watch?v=O1YjdKh-rPg
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan <http://twitter.com/paul_kinlan>
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan