Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-00.txt

[Dzonatas Sol <[e-mail]>]

On 05/16/2011 11:16 PM, Mark Nottingham wrote:
>
>> Thus we should probably have two distinct well known files. In order to
>> reduce the number of requests, we could suggest that if the browser-hints
>> file does not contain any connection information, then the browser is
>> invited to get /.well-known/connection-hints too as a complement.
>>      
> I have a pretty strong suspicion that this will end up being too complex, but let's see what others think.
>
>    

The ReSTful paradigm is useful here such that any specific field in the 
browser-hints file can be found by path.

GET /.well-known/browser-hints/max-conns

I'm sure this leads to PUT, POST, and DELETE methods as well for easier 
connection negotiation, management, and hints of what paths are 
streams/pipelines, or like capabilities.

For example, I use these next two to combine all data into one stream 
that appears like a structure, with the specific path:

GET /.well-known/browser-hint/s   # all hints with data in XML format
GET /.well-known/browser-hint      # list of categories known in XML format

As above:
GET /.well-known/browser-hints    # suggested default for JSON fromat

I suggest this "symbolic" reservation for *explicit* stream methods and 
logical devices  (combined path use-cases from SYSV, VMS, and 
IETF-VWRAP-LLIDL)
GET /.well-known/browser-hint$
GET /.well-known/browser-hint$max-conns

Conservative approach to avoid query arguments or extra headers that 
specify format:
GET /.well-known/browser-hint.xml         # XML alternative
GET /.well-known/browser-hint.json         # JSON alternative
GET /.well-known/browser-hint.json.xml  # json in XML format: 
https://datatracker.ietf.org/doc/draft-rsalz-jsonx

I think XSLT with optional script can be used for further 
transformations of paths and streams.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant