31–40 of 84 posts
"Internet Explorer cannot display the webpage" is what happens here (IE 8).
Not really a good reply, but I think that hashify.me's potential for an IE audience was probably small to start with. But consider this: if this idea took off, wouldn't this press MS into keeping IE more modern?
Very neat idea, but I think the reliance in bit.ly is self-defeating. This kind of approach would allow people to distribute documents using the web without having to trust them to a particular server, which can be very convenient if your target audience is in a country where access to the server storing your documents can be closed. For this to work you need to be able to recover the document from the URL locally. S…
I just can't see the gain here. You need a server to distribute the URLs in any case. You are just moving the data from the server that served the document to the server that servers the URLs. It is still the same data, just in different form.
For this to work you need to be able to recover the document from the URL locally.
How about saving the document?
Fuckify this ify trend to emulate or ride the spotify (anti)fame. Is it just me or does anyone else also just back away whenever there is a project which turns nouns into verbs with ify? Spotify is a sockpuppet of
I've sometimes wondered about a system where the URL of a document is an actual hash, like SHA-1, of the document. That'd chance the semantics of hyperlinks from "link to document at this internet address" to "link to document with these contents", just like Hashify does, but it could do arbitrarily large documents. The tricky part with that system would be that you'd also need some new mechanism to retrieve the file…
Earlier quoted context omitted.
Not really a good reply, but I think that hashify.me's potential for an IE audience was probably small to start with. But consider this: if this idea took off, wouldn't this press MS into keeping IE more modern?
My mobile browser of choice does not support cross browser resource sharing, according to the article...or rather the error message I get in lieu of the article.
I don't get it. Why do they claim that this is in any way better than a data:// url? ( http://es.wikipedia.org/wiki/Data:_URL )
Earlier quoted context omitted.
There is: "Storing a document in a URL is nifty, but not terribly practical. Hashify uses the [bit.ly API][4] to shorten URLs from as many as 30,000 characters to just 20 or so. In essence, bit.ly acts as a document store!" http://tinyurl.com/3n6h8px
This was my point, they're passing their 30,000 char URL to bit.ly to return a short URL (20 chars) But what happens if bit.ly just say "Sorry incoming URLS (long urls) can only be a maximum of 1500 chars"?
While the HTTP specification does not define an upper limit
on the length of a URL that a user agent should accept,
bit.ly imposes a 2048-character limit.I've sometimes wondered about a system where the URL of a document is an actual hash, like SHA-1, of the document. That'd chance the semantics of hyperlinks from "link to document at this internet address" to "link to document with these contents", just like Hashify does, but it could do arbitrarily large documents. The tricky part with that system would be that you'd also need some new mechanism to retrieve the file…
"A New Way to look at Networking" http://www.youtube.com/watch?v=8Z685OF-PS8