2 ms·
Neat idea, although I'm not sold on the style of the URLs themselves. It'd be cool to introduce a new URL scheme: code://github.com/edicl/hunchentoot/mast
by zeveb 10y ago
Neat idea, although I'm not sold on the style of the URLs themselves. It'd be cool to introduce a new URL scheme:
code://github.com/edicl/hunchentoot/master/log.lisp?macro=with-log-stream
That would handle multiple definition namespaces. One could use
code://github.com/edicl/hunchentoot/master/log.lisp?macro=with-log-stream&commit=0951a0df8fe93d99e6f2aa3f9612a2d6e581e84f
to refer to a particular commit. No idea what the equivalent would look like for other VCSes though.
- asimuvPR 10y agoI've been toying with roughly the same idea for some months. I've come up with new URL schemes for JSON objects[1], and (Iot)hings[2]. They differ in what they do but the purpose is to explore how specific URL schemes could open the door for improvements. [1] json://the-domain.com/example Would return: {"json":"data"} [2] thing://ip-address/example In this case, it returns JSON for the sake of readability, so: {"name":"car","speed":88,"location":"1985"}
- zeveb 10y agoWhat would be the advantage of those schemes over HTTP? In the case of code, I can see that there's a potential benefit to being able to refer to conceptual objects (e.g. variables, functions, macros) within version control systems, and maybe that's worth breaking with HTTP URLs, although I'm not completely sold there. What would the advantage of json: be over Content-Type: TYPE+json? It's a little easier to see that iot:UUID might indicate something like 'over any number of protocols, over any number of networks, please contact this device in my locality' or somesuch.
- asimuvPR 10y agoI'm exploring if there is a benefit to using new protocols for networked things. Mostly research. :)