Python-сообщество

http://repo.cat-v.org/py9p/
http://ru.wikipedia.org/wiki/SyncML

bw
>> А вообще. С такими ограничения следует бороться другими методами.
> И какими, если не секрет?

Дать админу сети водяры пузырь. Или по морде. Действовать по обстоятельствам в общем.

..bw

Боюсь, что в той сети много админов. Разорюсь или руки отобью. По обстоятельствам.

Если серьезно, то я виноват, не написал сразу, что сеть - это Сеть.

Lexander
По указанным данным получается, что по ГПРС нужно будет передавать пакеты мегабайт эдак в 15 за раз. Что, конечно, бред.
А вообще то я специально запросил диапазон, а не примерное значение. Ну да ладно, не хочешь, так и не надо.

Ну почему сразу 'не хочешь - не надо'. Хочу и надо, просто не понял что именно интересует.
Максимальное количество блоков - это вся база, такой тип синхронизации может быть только в самом начале, когда на одной стороне ничего нет. 
Если юзер захочет это делать через GPRS - флаг в руки, но думаю таких немного найдется.
Среднее количество блоков гораздо меньше - от нескольких десятков до максимум пары тысяч, не больше. В среднем ну может пару сотен.

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

Я понял и полностью согласен. Но отвечать на вопросы, которые не задают, я тоже не могу.

Если не накладывается ограничение на тип сети, то я бы посмотрел в сторону централизованного управления в противовес p2p с возможностью работы и как p2p именно на этапе передачи данных для тех устройств, где это возможно. С грамотной разбивкой пакетов (на сервере). И протокол передачи данных свой бы сделал - под те типы данных, что передаются. Использовал бы сокеты.

понятно. Значит велосипед нужно будет изобрести. Хех, опять :(

clopomor
http://repo.cat-v.org/py9p/
http://ru.wikipedia.org/wiki/SyncML

Спасибо за линки. Вы правильно уловили ход моих мыслей, несмотря на сумбур изложения.
Хотелось бы что-то типа SyncML, но более generic, не с такой жесткой структурой и с поддержкой передачи бинарных данных.
Но, видимо, я хочу странного и нужно просто делать еще раз то, что уже сотни раз сделано до меня.

OpenSync (http://www.opensync.org/) похоже близко к тому, что я искал. По крайней мере на первый взгляд.

Спасибо всем откликнувшимся!

Ed
Если юзер захочет это делать через GPRS - флаг в руки, но думаю таких немного найдется.

Могу с уверенностью заявить (есть опыт), что пользователи GPRS будут всячески минизировать трафик. И жаловаться на его объем вне зависимости от реального объема. Поэтому обрати внимание на минимизацию передаваемого объема данных: ничего лишнего, 10 раз предупреди GPRS-клиентов (и то не поможет :)), может быть даже подумай о специальных форматах передаваемых файлов (например, медиаконтент можно перекодировать и держать несколько вариантов для разных клиентов).

Ed
Значит велосипед нужно будет изобрести.

Отнюдь. Можно просто выбрать эффективный для твоих типов данных и его подстроить под себя. Посмотри в сторону торрент, например. Есть сервер (заведомо хорошо оснащенный и обеспечивающий хорошую производительность), где регистрируются и хранятся пакеты (если нужно обеспечить передачу данных на клиентов вне зависимости от доступности клиента, сгенерировавшего контент; если хранить не нужно, достаточно зарегистрировать пакет). Есть клиенты, которые к нему обращаются за “адресом” клиента-генератора или за пакетом (если клиент-генератор недоступен).
Если полнота информации или ее доступность не являются необходимыми критериями, то вообще можно торрент брать и не мучаться. Эффективность при передаче разного типа информации его доказана практикой.

Lexander
Могу с уверенностью заявить (есть опыт), что пользователи GPRS будут всячески минизировать трафик. И жаловаться на его объем вне зависимости от реального объема.

Это нормально, я в курсе. Думаю, что таких будет немного. По мне так проще приехать домой и синхронизироваться с десктопом, чем делать это через GPRS, если объем большой или трафик дорогой.

Значит велосипед нужно будет изобрести.
Отнюдь. Можно просто выбрать эффективный для твоих типов данных и его подстроить под себя.

Из чего выбрать? Я и искал generic решение, причем не для задачи синхронизации, а для передачи данных. Чего уж, кажется, стандартнее может быть. Ан нет. Пока кроме opensync ничего не вижу.

Посмотри в сторону торрент, например.

Торрент - это не то, что мне нужно. У меня контент изменяется как правило одним человеком, просто на разных компьютерах, как правило на переносном(телефон, ноут, наладонник) и на десктопе. Я уже писал, что довольно близким примером может быть синхронизация контактов/задач между, скажем, телефоном и email-клиентом. Отличие только в объемах, частоте и в том, что мой контент может(не обязательно) содержать изображения и звуковые файлы, то есть бинарные компоненты.

Иметь сервер в Интернете, через который можно синхронизироваться - это может быть запасным вариантом, но не основным. Наиболее частый вариант синхронизации - локалка или bluetooth/usb соединение. Вот такая специфика.

Ed
Упс. Можно поподробнее? Я считал, что D-BUS имеет немного другую область применения.

http://ru.wikipedia.org/wiki/D-Bus
D-Bus — это система межпроцессного взаимодействия, которая предоставляет приложениям несколько шин для передачи сообщений.

Просто в первом посте не слова небыло про то, что приложения на раных машинах.