in discovery set link *rel* to URI or just register spaceapi with IANA

[elf-pavlik]

as far as i understand we shouldn't use just a random term for rel attribute of link we could either use URI or register spaceapi with IANA http://www.iana.org/assignments/link-relations/link-relations.xhtml

SeeAlso: http://www.packetizer.com/webfinger/link_relations.html

relevant to #47

[elf-pavlik]

@slopjong i can't find on http://spaceapi.net/documentation explanation of how discovery works?

http://hackerspaces.nl/spaceapi/ has it in "Hosting considerations"

[slopjong]

The big problem is that the hosting considerations explain a discovery method which is some sort of inapplicable. To have domain.com/status.php as the default conflicts with other programming languages and it sounds odd for ruby/python developers to setup such a route.

In order to use the validator it needs to get the direct endpoint URL and also to submit it to the directory. If we used the link relation spaceapi for discovery of the actual endpoint URL overriding domain.com/status.php, how would any webapp be able to consume all the endpoints in a moderate manner (by not crawling the hackerspaces' websites first). Every HTTP request and parsing costs time so if we have regular website URLs in the directory every spaceapi app would need to fire extra requests, to parse the results and to make things more complicated than it should be.

Right now I have no clue how the discovery tag would improve the discovery mechanism. Personally I can't support the new link relation with the given arguments above. There are technical problems that are still unresolved.

The initial idea was good but its implementation is not trivial.

[slopjong]

I've just read #47. I've recently introduced the SpaceAPI in a couple of hackerspaces and they were more into hardware hacking and thus they were not too familiar with web technologies.

Reply follows in that ticket.

[elf-pavlik]

"To have domain.com/status.php as the default conflicts with other programming languages "

only rel part matters here space-api to recognize link we look for, and href one can set the location of endpoint, this way i just need to know homepage of hackerspace to discover it's space-api endpoint

it works similar to: http://www.rssboard.org/rss-autodiscovery

in general i want to need to know only homepage URI of a hackerspace and discover its space api endpoint from there by:

• GET request for homepage, search returned html for tag with rel="space-api", use value of href
• HEAD or GET request for homepage, look at Link HTTP header with rel="space-api", use value of href #47

in case of doing HEAD, i can fetch very minimum amount of data, just HTTP headers, to discover location of space-api endpoint :)

[brimstone]

I see no problem mimicking how RSS handles discovery. Two GETs when only having the domain of the hackerspace is good enough for me. If a webapp or something needs to scrape a mass amount of hackerspaces, it should either use the directory or precache the endpoint URL and fall back to the domain if the endpoint errors.

I didn't see anything that said 'rel="spaceapi"' was bad. My only guess is that none of the other rel values are specific implementations. If we really want to avoid 'rel="spaceapi"' would another value work instead? I can only think of a few cases when a HTML parser performs negatively when encountering improper syntax.

[slopjong]

I know how such kind of discovery works, I was simply assuming you thinking of a directory replacement.

RSS and SpaceAPI however have their differences. RSS capabilities are mostly built-in in CMS systems with community devs maintaining the code. Chances are very low that the rss link relation breaks.

In hackerspaces though you have many people working on many things and also breaking things - without noticing it. There's no permanent & active community that keeps an eye on a high availability and if something breaks it takes long to fix it.

Clients that have enough performance & bandwidth, they're free to use the link relations. Clients with limitations such as microcontrollers for example should always use the direct endpoint URLs to save requests and thus the directory is recommended.

Clients using the link relation the validator is bypassed which guarantees a certain quality. By using the directory you can always access information from broken endpoints because of the internal cache.

Though for experimental software the link relation is fine.

[elf-pavlik]

@slopjong I see directory you work on as something super useful in many use cases but I also see use cases where one may not even want to know about this directory existing :) I quite like this old presentation titled: "Discovery, Or how we interact with unknown?" http://hammer-lahav.smugmug.com/gallery/10428894_Qm9jR