Зачитал, все что выше...постараюсь свои мысли выдать структурировано:
1) Формат хранения данных:
Когда у тебя комп, то обход DOM не так страшен, так как проц грузится не особо на долго, дерево все размещать можно в оперативке, обращения к диску минимальны, НО(!) как только нужно будет переводить на уровень гаджетов, от-лайн синхронизации, возможности поделиться - сразу же упрешься во все замечательные ограничения хранилища на базе ФС. А в случае веб-сервиса для публикации и он-ланй синхронизации, даже если писать на очень быстром php и хранить базы где-то на amazon s3 - ну ты скорее амазон повесишь, нежели чем добьешься качественной работы сервиса. Я это говорю как человек с большим опытом администрирования, и хорошим понятием как делаются он-лайн сервисы. А производительность БД - это легко решается масштабированием БД или изначальной заточкой под движки типа couchdb. Как пример, я знаю работающие веб-решение, клиентоориентированное на базе php+Postgresql, где примерно порядка 7000 баз, к которым цепляется порядка 50000 клиентов, и все это крутится всего лишь на двух 4х процессорных серваках, да и к тому же с 32-битными операционками. И тормозов у БД нет, а вот например 1с с базами на основе ФС, начинает валиться на 4х клиентах, а 14 это максимальный предел хоть какой-то работы, в конечном итоге просто кладется вся ФС, огромные очереди на чтение-запись, огромная фрагментация. В БД эти вопросы решены на уровне синхронизации буферов с дисковой копией БД. Я не пытаюсь доказать, что выбранное тобой представление данных плохое, и не говорю - давай использовать SQL базу...оба этих пути могут быть тупиковыми. А могут и нет. Просто из личного опыта, я считаю, чем больше у тебя уровень абстракции между хранением данных и их представлением, тем проше развивать и переносить проект в современных условиях. К примеру выбрав хорошую ORM-библиотеку, ты сейчас завяжешь скажем локальную базу на sqlite, но потом легко сможешь переписать прогу (или дописать модуль) который буде работать с Ораклом....ну и т.д. Это просто как пример.
2) Синхронизация через дропбокс или гитхаб....блин! ненавижу костыли, они ломаются - а это КОСТЫЛЬ! Это хорошо будет работать для профи, вернее на том, кто понимает. Но, что делать, когда база начнет переваливать 2 гига (ограничение дропбокса) или там будут закрытые данные (бесплатные аккаунты на гитхабе открыты, да и к тому же ограничение в 300 метров)???? Или как пример, на новом месте придется провести полную синхронизацию с дропбоксом или гитхабом, прежде чем начать работать...то есть ты в командировке, нет толкового инета, кроме 3G (дай бог) и ты сидишь и ждешь когда твои ндцать мегабайт придут к тебе...
Очень рекомендую ознакомиться с Evernote!
Со своей стороны могу помочь с .....разбиванием идей и привнесением новых, так как понимаю и программирование и администрирование и удобство пользования, могу помочь с организацией групповой разработки, багтрекинга и тд, хорошо разбираюсь в вебсервисах, построении нагруженных решений. Пишу на python и ruby.
rudenkovk at gmail.com