Веб-страница = URL

[@outcoldman]

Круто конечно, но зачем? В любом случае текст нужно где-то хранить. Так он будет в bit.ly получается. Но есть pastbin тот же и еще куча сервисов.

[@diamant]

Можно написать программку, чтобы фильмы в HD хранила на bit.ly :)

[@TheAlien]

По-моему изврат какой-то…

[@Sagaris]

wp.shkolnikov.me/wp-content/uploads/2010/05/why.jpg

[@SlackFolk]

Некоторые люди любят всякого рода извращения:)

[@hx0]

HTTP судя по всему

[@Ex3NDR]

в HTTP нет указаний на максимальную длинну запроса/ссылки и т.д.

[@vanfukov]

— How many Microsoft workers do you need to change the light bulb?
— Zero, they'll make darkness a standard.

[@sainnr]

HTTP/1.1, RFC2616:
«The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle»

Т.е., протокол ограничений не накладывает, всё зависит от сервера и от браузера. Про браузеры подробнее здесь: www.boutell.com/newfaq/misc/urllength.html

[@BarsMonster]

Да, это как двигатель перебирать через выхлопную трубу )
Но такие безбашенные вещи мне нравятся :-)

[@Sagaris]

а чем это по сути отличается от сокращения УРЛ на закешированную на гугле страницу?

[@Delfino]

Согласен с автором, что важна новая концепция. Например, dropbox не является чем-то технологически новым: создай ftp/http-сервер, rsync, бла-бла. Но они предложили новый user experience. А это весомо.

[@grimskin]

Емнип, дропбокс еще красивее поступил. У них не «ftp/http-сервер, rsync, бла-бла» а svn.

[@Delfino]

Ну subversion — тоже технологически не ново :)

[@grimskin]

Не ново, но в итоге получается не машап имеющихся технологий, а красивое применение уже имеющейся. Что, имхо, круче.

[@Delfino]

Собственно, как и сабж :)

[@Sagaris]

А для пользователя какой PROFIT, если он все равно видит только ссылку на bit.ly?

[@burdakovd]

Да не в url текст находится, статью же alizar писал =)

Текст находится в bit.ly, а url, как ему и положено _указывает_ на контент.

Тут по сути строится B-дерево высоты 2 (почему кстати не больше?), где корнем является ссылка, данная пользователю.
Контент узлов дерева хранится в bit.ly, в листах хранятся собственно данные, а в промежуточных узлах ссылки на дочерние узлы.

Кстати есть ещё безумная идея-обобщение от которой bit.ly будет в шоке!

Интерпретировать url как указатель на область памяти размером 2048 байт, bit.ly как ЗУ.
API такого ЗУ будет довольно специфическим — содержимое каждого блока памяти можно инициализировать при создании, и потом менять нельзя, можно только создавать новые блоки.

Но с помощью такого API можно строить любые персистентные структуры данных — одно(двух)связные списки, деревья поиска и много другого! Размер таких структур *теоретически* неограничен.

А если применить шифрование, то эти данные будут ещё и защищены от просмотра посторонними лицами, в том числе и сотрудниками bit.ly.

А дальше строим bitlyfs, использующую в качестве бэкенда bit.ly. Особенностью этой fs будет то, что т.к. бэкенд персистентный — то хранятся все версии файлов в этой файловой системе, получается типа VCS.

А если bit.ly удаляет неиспользуемые ссылки спустя какое-то время, то получаем некоторое подобие человеческого мозга — данные в этой fs, которые долго не использовались будут «забываться».

Ух, какие перспективы!

[@bes_internal]

Бедный bit.ly

[@Sagaris]

Так это же и есть искусство маркетинга! Вам предлагают совершенно новый продукт в котором нет ничего лишнего. А купив к нему дополнительные компоненты вы сможете его использовать практически так же как старый.

[@w495]

А что вы хотели? Интернеты по таким законам развиваются. Вспомните, что было (планировали) с масками подсети изначально, а что стало потом.

[@vladon]

а что было? расскажите плз

[@w495]

Подробно и правильно объяснять — долго, тем более оффтоп. Сначала придумали классовую адресацию сетей, а потом способы ее обхода (маска подсети).

[@Murevich]

Вот если бы они торрент файлы в ссылку хэшировали тогда да.
А так — малополезный сервис.

[@zodiac]

Можете сделать.

[@SokoloffP]

А чем magnet-ы не устраивают?

Да и нет никаких проблем содержимое торрент-файла в base64 закодировать.

[@tangro]

То-то bit.ly удивился, когда узнал, что он теперь хранит контент чужив веб-страниц (со всеми последствиями технического и юридического плана).

[@diamant]

тест: bit.ly/fP2r9y

 

[@vitroot]

не проще было ссылку на пост в ленте укоротить и все? :)

[@Sagaris]

Опера 11.10. Не открыло.

[@winger]

Как и мобильный safari

[@EvgeniyLazarev]

[irony]Почему в новости нет координат места события?[/irony]

[@AndreyNagih]

А вы бы хотели съесть эту колбасу???

[@weiiis]

В этом тесте у меня все ссылки ведут на hashify вместо того, куда бы логично было… на lenta.ru
То есть, в принципе, можно только голый текст вешать?
А еще совсем неудобно получается, что вся страница справа, это делает полосу прокрутки.
Этот редактор слева — мешает.

Короче, не лучше обычных paste-bin- ов.

[@vitroot]

Какого-то многообещаущего практического применения не обнаружил.
Было бы неплохо, если бы твит с такой ссылкой сам твиттер воспринимал, например, как изображение с длинным сообщением или еще как-то… Хотя… тогда твиттер перестал бы быть твиттером, а превратился бы в жж

[@Serrega]

Надеюсь, что идея не доберется до оффлайновых хранилищ

[@vitroot]

Теперь не обязательно скриншотить особо компротатные страницы, пока их не удалили. Можно вот так закешировать и выдавать по необходимости :)

[@peanut]

О! Мсье знает толк в извращениях!

[@Pozadi]

Bit.ly — теперь и хостинг.

[@sainnr]

Да, осталось теперь написать CMS на основе данной технологии…

[@deniamnet]

теперь со вкусом хостинга!

[@Xpeh]

Однажды один математик объявил премию любому, кто напишет для него идеальный архиватор: программу, которая сожмёт произвольный входной файл хотя бы на байт, и сможет распаковать обратно. Десятки людей присылали ему свои программы, и математик неизменно находил для каждой из них такой входной файл, который она сжать неспособна, пока не появился однажды герой, зашифровывающий один байт исходного файла в расширении сжатого и утверждающий, что его программа подбирает для сжимаемого файла наиболее оптимальный формат и поэтому разные расширения у сгенерированных файлов легитимны. И разозлился математик страшно, и стали передавать историю об этом программисты из поколения в поколение.

[@Xpeh]

Ах да, пруфлинк: www.cs.fit.edu/~mmahoney/compression/barf.html

[@besisland]

Парсер не любит 1990-е, кажется.

[@TheShock]

и математик неизменно находил для каждой из них такой входной файл

Файл из нуля или одного байта?

[@Rihtor]

Клевая!

[@PycoBeg]

Очень бы хотелось ещё видеть в сервисе быструю возможность закешировать подобным образом страницу в одном из специфических режимов: полный, без скриптов, без картинок на внешних доменах, «только текст».

А вообще, соглашусь со многими комментировавшими выше — сервис достаточно специфический, но тем не менее, если сервис два-три раза выручает — это уже значимый сервис (имхо, конечно).

[@Irokez]

Надо бы через gzip еще пропустить перед кодированием