передача файлов в разных im на моей памяти неоднократно ломалась и начинала работать опять. Впрочем, в последнее время она довольно устойчиво зависла в состоянии «не работает». Я возмутился, что мой реальный IP никак не помогает, и решил разобраться с проблемой. Основную часть мне удалось решить
кратко: для успешной отправки файлов достаточно указать в настройках клиента свой внешний ip-адрес или домен и пробросить нужный порт. То есть, если у вас стрим и вы используете нечто вроде DynDNS, то всё просто. Конкретных рекомендаций не буду давать, клиенты все разные
а теперь подробности. Стандарт описывает два способа передачи:
отправитель имеет реальный ip или контроль над своим NAT
отправитель знает socks5-прокси, с которым могут соединиться оба участника
из этого следует, что если вы хотите получить от кого-то файл, и этот человек — не технарь, то скорее всего вам нужно искать другие способы передачи. А вот для отправки файла можно немного повозиться. Лучше всего, конечно, знать свой внешний ip и иметь проброшенный порт. Иначе придётся добывать прокси. Но публичные прокси мало кто держит — редкий человек будет оплачивать такие объёмы трафика. Можно поднять свой, но тут другие проблемы. Во-первых, абы какой socks5 не подойдёт, тут нужны некоторые расширения, которые реализованы, видимо, исключительно в jabber-серверах. Во-вторых, сервер должен принимать подключения и от тех, кто хочет послать вам файл, поэтому придётся заморочиться с авторизацией или терпеть огромный трафик от анонимусов, которые скоро обнаружат эту проксю
опытный человек может возмутиться, что всю жизнь для p2p было достаточно одного реального IP у любой стороны. Да, это так. Но спека на socks5 bytestreams в джаббере требует этого именно от отправителя. Psi реализует нестандартное расширение, позволяющее обходиться реальным адресом у получателя, но черновик его был зарублен и не стал стандартом, поэтому фичу убрали из Gajim. Теоретически всё может работать и посредством jingle file transfer, но эта спека ещё не стала даже черновиком
у меня в голове давно уже вертится сравнение html и php. Эти технологии сильно похожи между собой в плане устойчивости к ошибкам идиота автора-любителя. Можно написать почти какую угодно чушь, и она будет как-то понята браузером или интерпретатором. Эта особенность невероятно сильно сыграла на руку обеим технологиям: каждая из них стала потрясающе популярной. Из этого можно сделать вывод, что для массового распространения системы нужно делать её максимально дуракоустойчивой, что достижимо, только если не особо задумываться о «правильности» применяемых решений.
однако, приобретая такую популярность, технология роет самой себе большую яму. Миллионы любителей используют самые неудачные особенности первых версий, и полагаются на страннейшие свойства защиты от дурака. И чтобы не потерять главную ценность — базу пользователей — технологии приходится очень сильно вкладываться в обратную совместимость. Поэтому она асимптотически устремляется к состоянию, когда чуть менее, чем полностью, состоит из legacy.
тут я хотел сослаться на хороший пост Станиса «Жрецы программирования», но его блог, видимо, умер, поэтому придётся передать мысль своими словами. Есть различие между «магами» и «жрецами». У жрецов очень развита память, поэтому они дословно помнят канон и кучу томов комментариев к нему. У магов память слабее, зато развит логический аппарат, поэтому они находят в данных взаимосвязи, и запоминают только их, сохраняя при этом способность восстановить исходные данные. К компьютерным системам эту идею можно приложить вот как: в high-legacy системе автору нужно помнить огромное число логически бессвязных особенностей (и даже не пытаться обобщать их), тогда как в случае low-legacy достаточно знать небольшой набор правил, описывающих множество случаев. Менее очевидна мысль о том, что хороший программист в первую очередь специализируется на поиске закономерностей и обобщении, поэтому работа с legacy непосредственно вредит ему своим запретом на обобщения.
справедливости ради следует отметить, что проблема legacy в случае php и html возникает из-за их сильной централизации. Скрипты на php обычно свалены тысячами у одного хостера с одной версией языка. Веб-страницы на html так вообще просматриваются жалким десятком (ну пусть даже двумя десятками) браузеров. А вот в случае тоже ориентированной на любителя jquery этой проблемы нет, потому что каждый любитель сам выбирает, с какой версией библиотеки будут работать его скрипты, и это не изменится даже через десять-пятнадцать лет.
читатели блога наверняка давно заметили, что одна из самых популярных тем здесь — юзерскрипты. (Кстати, называть их гризманки-скриптами неграмотно.) К сожалению, интерфейсная поддержка этой мощной функциональности в опере хромает: всего-то можно указать папку с ними и переопределить её для отдельных сайтов. Конечно, это не мешает решать те же самые задачи, но так они занимают немного больше времени, чем в том же гризманки.
поскольку у нас пока ещё нет возможности писать под оперу такие же аддоны, как под фф, с проблемой юзерскриптов поделать ничего нельзя. Хотя постойте! Можно делать под оперу виджеты, а для них ещё год назад заявляли поддержку File I/O. Значит, можно сделать виджет, который даст удобный интерфейс управления скриптами! И не только ими, можно много чего навертеть, почти как для фф…
да, действительно можно. И оно даже будет работать. Но как тег video и 3d canvas. То есть, только в экспериментальном билде : (