http://repo.cat-v.org/py9p/
http://ru.wikipedia.org/wiki/SyncML
bwБоюсь, что в той сети много админов. Разорюсь или руки отобью. По обстоятельствам.
>> А вообще. С такими ограничения следует бороться другими методами.
> И какими, если не секрет?
Дать админу сети водяры пузырь. Или по морде. Действовать по обстоятельствам в общем.
..bw
LexanderНу почему сразу 'не хочешь - не надо'. Хочу и надо, просто не понял что именно интересует.
По указанным данным получается, что по ГПРС нужно будет передавать пакеты мегабайт эдак в 15 за раз. Что, конечно, бред.
А вообще то я специально запросил диапазон, а не примерное значение. Ну да ладно, не хочешь, так и не надо.
Вообще то я написал не полный список вопросов, дал понять, что вопросы возникли и их много. Вопросы и ответы на них дадут полную картину и, возможно, ответ придет сам собой.Я понял и полностью согласен. Но отвечать на вопросы, которые не задают, я тоже не могу.
Если не накладывается ограничение на тип сети, то я бы посмотрел в сторону централизованного управления в противовес p2p с возможностью работы и как p2p именно на этапе передачи данных для тех устройств, где это возможно. С грамотной разбивкой пакетов (на сервере). И протокол передачи данных свой бы сделал - под те типы данных, что передаются. Использовал бы сокеты.понятно. Значит велосипед нужно будет изобрести. Хех, опять :(
clopomorСпасибо за линки. Вы правильно уловили ход моих мыслей, несмотря на сумбур изложения.
http://repo.cat-v.org/py9p/
http://ru.wikipedia.org/wiki/SyncML
EdМогу с уверенностью заявить (есть опыт), что пользователи GPRS будут всячески минизировать трафик. И жаловаться на его объем вне зависимости от реального объема. Поэтому обрати внимание на минимизацию передаваемого объема данных: ничего лишнего, 10 раз предупреди GPRS-клиентов (и то не поможет :)), может быть даже подумай о специальных форматах передаваемых файлов (например, медиаконтент можно перекодировать и держать несколько вариантов для разных клиентов).
Если юзер захочет это делать через GPRS - флаг в руки, но думаю таких немного найдется.
EdОтнюдь. Можно просто выбрать эффективный для твоих типов данных и его подстроить под себя. Посмотри в сторону торрент, например. Есть сервер (заведомо хорошо оснащенный и обеспечивающий хорошую производительность), где регистрируются и хранятся пакеты (если нужно обеспечить передачу данных на клиентов вне зависимости от доступности клиента, сгенерировавшего контент; если хранить не нужно, достаточно зарегистрировать пакет). Есть клиенты, которые к нему обращаются за “адресом” клиента-генератора или за пакетом (если клиент-генератор недоступен).
Значит велосипед нужно будет изобрести.
LexanderЭто нормально, я в курсе. Думаю, что таких будет немного. По мне так проще приехать домой и синхронизироваться с десктопом, чем делать это через GPRS, если объем большой или трафик дорогой.
Могу с уверенностью заявить (есть опыт), что пользователи GPRS будут всячески минизировать трафик. И жаловаться на его объем вне зависимости от реального объема.
Значит велосипед нужно будет изобрести.Из чего выбрать? Я и искал generic решение, причем не для задачи синхронизации, а для передачи данных. Чего уж, кажется, стандартнее может быть. Ан нет. Пока кроме opensync ничего не вижу.
Отнюдь. Можно просто выбрать эффективный для твоих типов данных и его подстроить под себя.
Посмотри в сторону торрент, например.Торрент - это не то, что мне нужно. У меня контент изменяется как правило одним человеком, просто на разных компьютерах, как правило на переносном(телефон, ноут, наладонник) и на десктопе. Я уже писал, что довольно близким примером может быть синхронизация контактов/задач между, скажем, телефоном и email-клиентом. Отличие только в объемах, частоте и в том, что мой контент может(не обязательно) содержать изображения и звуковые файлы, то есть бинарные компоненты.
Ed
Упс. Можно поподробнее? Я считал, что D-BUS имеет немного другую область применения.
http://ru.wikipedia.org/wiki/D-BusПросто в первом посте не слова небыло про то, что приложения на раных машинах.
D-Bus — это система межпроцессного взаимодействия, которая предоставляет приложениям несколько шин для передачи сообщений.