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

[Dzonatas Sol <[e-mail]>]

For those interested in interoperability of where I suggested ReSTful 
paradigm, here is one use-case:

Portable web-server in client web-browser, see here for basis without 
network installed:  http://bellard.org/jslinux 
<http://bellard.org/jslinux/tech.html>
Technicals: http://bellard.org/jslinux/tech.html

Imagine several dozens of those in one web page; then, the gist of how 
all instances can update or save themselves through provider means is 
little more obvious. I thought the above is useful reference to further 
design intermediary states and stateful/stateless implementation, 
especially where each instance/region is thought in terms of IPv4 and 
the outer frame is IPv6.

The complete idea of this use-case includes capabilities that enable 
intermediate systems rather be stuck in monolithic support requirements: 
"How do we save all these great ideas and not need to implement one 
single way?"

On 05/17/2011 07:07 AM, Dzonatas Sol wrote:
> 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