On Oct 25, 2005, at 12:59 AM, A. Pagaltzis wrote:
I am asking if is there a generic way for an application to
implement alternate-link processing that gives sensible behaviour
for any type of main link. If an implementor has to support
alternative links explicitly for each type of main link, where’s
the difference to having specific relationships for alternative
links depending on the main link type?
Here are a few examples of generic processing algorithms an
application might use:
Mirrors:
1) Randomly selecting a mirror to download from, thus helping to
spread the bandwidth usage among them.
2) Try the main link, and if the DNS lookup fails, or a connection
can't be made or something, automatically try the next one.
3) Ping each of the servers in the background, and if the user clicks
the link, use the fastest one.
Alternates:
1) Have a prioritized list of formats, and choose the link that
points to the highest priority format.
2) Of all the formats the app supports, choose the one with the
smallest @length, if present.
Either one:
1) Show some sort of UI for selecting which link to follow (perhaps
have the main link selected by default, but allow the user to select
an alternate from the popup).
None of those ideas is necessarily tied to any particular link
relation. They might be more important for enclosures than any of
the other relations that have been defined so far, and an application
may or may not do some for enclosures that it doesn't do for some
other specific link relations. But again, it comes back to the yet
unanswered question, are there any disadvantages to keeping it
generic? I haven't heard anyone suggest any downside yet--only that
some people can't imagine why anyone would want to use alternative
links for anything but enclosures.