3 ms·
it might be a bastardization of meta, but there must be a way to stuff this metadata into the existing structures, possibly even HTTP headers (I remember RSS au
by nikcub 15y ago
it might be a bastardization of meta, but there must be a way to stuff this metadata into the existing structures, possibly even HTTP headers (I remember RSS auto-discovery going through a similar development process.). my initial thought was:
<meta property="app:type" content="image/jpg,img/gif" >
<meta property="app:handler" content="open" >
and use canonical as the href. you can have multiple handler types, which are standard types, and then handers are actions
the concern that I have is that with the types this is just file extensions being moved to the web and all the problems that caused in desktop computing. ie. associating applications with file types. but you are saying that there is no default handler, that you get something more akin to an 'open with' which lists the applications that can handle that type
can you email me (email in profile) to discuss further, or is there a mailing list? I am interested in this area and have seen a number of 'web app/widget discovery' initiatives over the years but none really took off
(edit: code didn't show up)
- gbhn 15y agoI've talked with Paul a bit about this. We've also mocked up using link tags, which carry a bit more metadata. Probably the most promising approach, though, is using other webapp manifest ideas to bundle intent provider installation with that. (a la http://lwn.net/Articles/419151/ http://lwn.net/Articles/419151/)
- groby_b 15y agoNot a huge fan of the link tag. It's mutated by now into the "this is somewhat related to this page, somehow" tag. (I mean, seriously, rel="sidebar"?) I'd think in terms of semantics, the <embed> tag is more appropriate. If you want to re-use existing tags at all, that is.