Заплачу $ за реализацию небольшой фичи из багтрекера!

[Tolik]

Если это можно сделать средствами ХР, НЕ в пределах одного логического диска
...
Копирование батником файлов меток туда-сюда не предлагать.

Я думаю, копирование туда-сюда - это единственный способ при данных условиях.

[Tikh]

Если это можно сделать средствами ХР, НЕ в пределах одного логического диска
...
Копирование батником файлов меток туда-сюда не предлагать.

Я думаю, копирование туда-сюда - это единственный способ при данных условиях.

Жаль.

Будем надеяться, что кто-то из разработчиков заинтересуется моим предложением и назовёт цену за реализацию.

[Parasite]

Всё, дальше читать что-то расхотелось.
Ну ладно, допустим, оно уже есть и работает.

Озвученный топикстартером вариант "в локальной сети несколько десятков пользователей САС.Планеты" кагбэ намекает нам, что одним локалхостом там конфиг не ограничивается.

Как это поможет хранить метки отдельно от программы?
Всё равно писать bat-файл, который их копирует туда-сюда? Тогда зачем DFS? Я не понимаю, честно.

DFS может быть частью локальной ФС (прозрачно для любых приложений), при этом физически существуя "где-то там" (можно в разных местах для каждой своей части) и управляясь централизованно. При этом не теряются такие фичи как пермишны и "хардлинки в пределах тома".

Эту фичу я предлагаю добавить в основную версию, которая доступна всем.
...
Возможно, увидев моё предложение, кто-то из разработчиков выделит на программу дополнительно N минут своего времени.

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

Копирование батником файлов меток туда-сюда не предлагать.

Тогда объясните мне свое видение ситуации "ОДИН файл открывается ДВУМЯ пользователями на запись одновременно через приложение, хотящее монопольныого доступа к". Это же будет относиться и к работе через линки, так что ждемс.
Если не сможете - то тему переименовываем в "Хочу многопользовательской работы с метками!" (а это потребует базовода как минимум, и это будет совершенно другая хотелка) вместо "Хочу указывать любое местонахождение к файлу меток", и начинаем заново. Пока что у Вас подтверждена фича "местонахождение" (она действительно не так и сложна), но не "многопользовательность" (коя на порядки сложнее в реализации).

[vasketsov]

Мне нужна версионность кэша уже 4й год, к примеру

Ну заяц погоди подожди чуток, СУБД очевидно с версиями будет, только сейчас делов навалилось - пришлось отложить это дело.

я не отрицаю, что фича нужная. Я не отрицаю, что сейчас ее можно решить криво и через костыли - но таки решить прямо сегодня, если приложить руки. Я не отрицаю, что работы в ее направлении - необходимы, если костыли не нравятся. Но вот с выпячивания "Лично мне это нужно ЩАС, разработчики бросайте всё и делайте то что нужно лично МНЕ - а остальные (читай-бесплатные, сирые и юродивые) хотелки могут и подождать!" меня как-то воротит.
Мы все тут в равноправной очереди, знаете ли - и номерки у всех на ладошках написаны багтрекером успешно выданы.

Имею в наличии _полностью_ аналогичные "ааащущения".

>но не "многопользовательность" (коя на порядки сложнее в реализации).
Всё так. Ну даже будет общий файл с метками - что с того, что первый пописавший в метки, залочит всех целиком? Это исключительно либо видимость многопользовательской работы, либо метки только для чтения. В обоих случаях задача проще и корректнее решается батником и копированием меток. Тот есть либо я реально не понимаю чего хочет ТС, либо он не понимает что его ждёт, либо то что он хочет, он с реализацией отдельной ссылки на метки для *дцати своих подопытных леммингов не получит.
У меня есть стойкие ощущения, что без хранения меток в СУБД реальной "многопользовательности" в части меток не получить. Я буду исключительно рад, если беркли заработает в многопользовательском режиме, но что-то мне подсказывает, что придётся ждать возмоности подключения "взрослой" СУБД. А метки в СУБД у меня запланированы ТОЛЬКО после того, как тайлы там научимся хранить, да и насколько там vdemidov интерфейсы пописал, чтобы можно было по одной метке читать-писать в хранилище - тоже ещё не смотрел даже. В общем, это пока что выглядит как совсем далёкая тема.

[Tikh]

Касаемо результата реализации - я понимаю, что это будет сильно ограниченная многопользовательность меток.

>>У меня есть стойкие ощущения, что без хранения меток в СУБД реальной "многопользовательности" в части меток не получить. Я буду исключительно рад, если беркли заработает в многопользовательском >>режиме, но что-то мне подсказывает, что придётся ждать возмоности подключения "взрослой" СУБД. А метки в СУБД у меня запланированы ТОЛЬКО после того, как тайлы там научимся хранить, да и >>насколько там vdemidov интерфейсы пописал, чтобы можно было по одной метке читать-писать в хранилище - тоже ещё не смотрел даже. В общем, это пока что выглядит как совсем далёкая тема.

Я предлагал в багтрекере гораздо более просто решение реализации многопользовательских меток.
СУБД - это страшно и сложно. Моя идея в том, чтобы хранить метки в виде 1 метка = 1 файл sml/xml. Подпапки в папке Marks - это категории меток. Соответственно программа читает структуру подпапок и файлов папки Marks и в такой же структуре выводит категории и метки в программе.
Это сразу убивает, наверное, всех зайцев. Автоматически средствами операционной системы получается и многопользовательская работа (одновременно при редактировании занят лишь 1 файл с меткой) и разграничение прав доступа на различные категории меток для разных пользователей (средствами Active Directory).
Проблема множества мелких файлов будет, считаю, не так актуальная как для кэша. Даже если будет 10 тысяч меток, для файловой системы это не так страшно, в кэше их сейчас гораздо больше.

[vasketsov]

Моя идея в том, чтобы хранить метки в виде 1 метка = 1 файл sml/xml

Попробуй скопировать 100 мегабайт по сети одним файлом, а потом 100 тыщ файлов по килобайту.
О результатах можешь даже не отписывать...

>СУБД - это страшно и сложно
Не настолько, как думается. А по мне так наоборот, всё просто и понятно, в отличие от AD.

[Parasite]

Я предлагал в багтрекере гораздо более просто решение реализации многопользовательских меток.

Так не бывает.

Проблема множества мелких файлов будет, считаю, не так актуальная как для кэша. Даже если будет 10 тысяч меток, для файловой системы это не так страшно, в кэше их сейчас гораздо больше.

А теперь попробуйте их (хранящиеся на сервере) оперативно ссинхронизировать с локальным САСом хотя бы для того, чтобы уведомить оный об изменении в метке ХХХ, сделанной соседним хомяком.

СУБД - это страшно и сложно

Не страшнее чем писать посты тут на форуме (а они - сюрприз! - токи вполне себе в базе данных).

[Tikh]

Моя идея в том, чтобы хранить метки в виде 1 метка = 1 файл sml/xml

Попробуй скопировать 100 мегабайт по сети одним файлом, а потом 100 тыщ файлов по килобайту.
О результатах можешь даже не отписывать...

Да я в курсе этого всего. У кого будет 100 тысяч меток? У считанных единиц пользователей, если вообще будет у кого-то такое количество. Далее. Даже при таком количестве, никакой беды не произойдёт. Я архивировал и копировал свой кэш с миллионом файлов, не то, что со 100 тыщами. За сутки сервер справился, я скопировал файл. Даже если у кого-то будет 100 тыщ меток, да, будут неудобства, но а) пользоваться будет можно, б) даже у этих пользователей, случаи, когда надо перегнать куда-то все метки будут возникать нечасто

>СУБД - это страшно и сложно
>Не настолько, как думается. А по мне так наоборот, всё просто и понятно, в отличие от AD.

Если у кого-то есть насущная потребность разграничивать права в САС, то такая потребность у них наверняка возникла гораздо раньше, для других типов документов. А значит, вероятнее всего, AD у них уже есть. Если не AD, то простое виндовое разграничение прав на доступ. Т.е. если использовать средства ОС, то самим разработчикам САС городить разграничение прав не нужно.

[Tikh]

А теперь попробуйте их (хранящиеся на сервере) оперативно ссинхронизировать с локальным САСом хотя бы для того, чтобы уведомить оный об изменении в метке ХХХ, сделанной соседним хомяком.

Зачем сразу такой крутой функционал? Просто загружать метки один раз, при запуске программы.

Не страшнее чем писать посты тут на форуме (а они - сюрприз! - токи вполне себе в базе данных).

Как оказалось страшнее - нововведённый кэш Беркли любит умирать, и вообще насколько я понял (могу ошибаться) не очень-то и дружит с многопользовательским доступом.
Кэш-то ладно, его потерять не страшно. А вот потеря БД с метками будет катастрофой.

[vasketsov]

Я архивировал и копировал свой кэш с миллионом файлов, не то, что со 100 тыщами

Вот видишь, архивировал, значит мозг ещё не отказал.
Считай, что сейчас метки и лежат в архиве.

За сутки сервер справился, я скопировал файл

Прога грузит метки при запуске.

если у кого-то будет 100 тыщ меток, да, будут неудобства

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

случаи, когда надо перегнать куда-то все метки будут возникать нечасто

Вопрос касается запуска программы, а не бэкапирования всех меток.

Если у кого-то есть насущная потребность разграничивать права в САС

Как бы БД и права - совершенно ортогональные вещи. Можно и в БД всей общагой ходить под сисадмином, и без БД права раздать.