ситуация вроде как банальная, но ранее не сталкивался:

- в приложении необходимо будет вести лог(и)/историю(и) сообщений прикладного ( пользоватeльского ) уровня
- по T3 использовать надо или файловую систему, или встроенную в приложение библиoтеку для работы с XML
- основной и единственный пользовательский режим чтение(поиск) по:

   - id source - ид. источника ( строго фиксированный - в рамках текщего контекста приложения )
   - datetime stamp - вчера, день, неделю, ..., все время ( задается пользователем )
   - text in message - текст для поиска в сообщении ( задается пользователем )

в случае с ипользованием XML вроде особых проблем нет...

а в случае использования файлухи, что-то не особо вырисовывается, пока набросал следующюю схему:

a. app_DIR->id_source_DIR->year[20xx]_DIR->month_[1-12].LOG_FILE

b. возникает вопрос по внутренней структуре month_[1-12].LOG_FILE - думается припаять
хранение сообщений прикладного уровня в TLV структуре( и также в TLV пркирутить необходимyю служебную хрень вроде заголовка лога и т.д.)

если кто пересекался с подобной проблемой
и/или пересекался с граблями схожей схемы на файловой системе - был бы благодарен услышать мнение(я)

- достаточно ли "правильно" ?
- подводные грабли ?

p.s.:
вообщем с одной стороны надо заложить какой-то базис для расширения,
с другой не охотa двухколесную промышленность развивать.

• аппликуха и варианты логгирования,Square, 18:38 , 25-Июн-15
  • аппликуха и варианты логгирования,fail_, 20:43 , 25-Июн-15
    • аппликуха и варианты логгирования,Square, 21:06 , 25-Июн-15
      • аппликуха и варианты логгирования,fail_, 22:07 , 25-Июн-15
      • аппликуха и варианты логгирования,fail_, 22:36 , 25-Июн-15
        • аппликуха и варианты логгирования,universite, 09:29 , 28-Июн-15
          • аппликуха и варианты логгирования,fail, 12:51 , 28-Июн-15

>    - id source - ид. источника ( строго фиксированный
> - в рамках текщего контекста приложения )
>    - datetime stamp - вчера, день, неделю, ..., все
> время ( задается пользователем )
>    - text in message - текст для поиска в
> сообщении ( задается пользователем )

Жжоте :)

filename.log
id application <tabulation> id source <tabulation> datetime stamp <tabulation> text in message

формат называется CSV, описан тут: https://ru.wikipedia.org/wiki/CSV

Широко используется в ИТ последние лет 50 :)

> Жжоте :)
> filename.log
> id application <tabulation> id source <tabulation> datetime stamp <tabulation> text in
> message

id source <tabulation> datetime stamp <tabulation> message
так было бы корректней сказать в данном предложении;
text in message - это что искать в сообщениях, не совсем правильно поняли

> формат называется CSV, описан тут: https://ru.wikipedia.org/wiki/CSV
> Широко используется в ИТ последние лет 50 :)

про csv и прочие "a:b:c" в курсе:

- кортежи выходят дюже "фиксированные" - трабля даже на cr, lf всплывает: уже +1 к  костыллингу при этом подходе + по моим прикидкам будут еще 2-3 итерации улучшизмофф и поликостыллинга пока "хотелки и ресурсы не устаканятся и прийдут в равновесие"

пока по файлухе все же видится:
app_DIR/id_source_DIR/year[20xx]_DIR/month_[1-12].LOG_FILE
+
month_[1-12].LOG_FILE с внутренней структурой на базe TLV

>> Жжоте :)
>> filename.log
>> id application <tabulation> id source <tabulation> datetime stamp <tabulation> text in
>> message
>  id source <tabulation> datetime stamp <tabulation> message
> так было бы корректней сказать в данном предложении;
> text in message - это что искать в сообщениях, не совсем правильно
> поняли

Зачем что-то искать? Вы вообще о чем?

Вы написали, что пишите приложение, которое будет шпионить за действиями пользователя ( вести лог) и далее описали какие данные хотите видеть в этом логе.
id source <tabulation> datetime stamp <tabulation> message

message - это и есть я так понимаю описание действий пользователя.. названия кнопок,вводимый текст... координаты мышки...

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

если вы далее с этими логами (это же логи, не база данных) планируете что-то делать вроде парсинга и извлечения из них данных, полнотекстового поиска по ним... это совершенно другая задача...
и лучше сразу засовывать логи в нечто-базоподобное....xml например.или просто в базу...встроенную напрмиер..чтото вроде sqlite

То есть вопрос вобщем то простой:

вы хотите обеспечить в этой программе логирование (воспользовавшись готовыми отлаженными механизмами) или хотите под предлогом этой работы изобрести свою собственную файл-ориентированную базу данных.

На мой взгляд - это совершенно разные задачи :)

PS: SqLite поддерживает тип данных blob- можно пихать что угодно :)

> Зачем что-то искать? Вы вообще о чем?

наверное вы не внимательно прочли первый пост;

пользователь будет искать (например текущая статистика: per 'id source' раз в квартaл) в истории  какие-то данные; возможно даже через regexp и/или пакетной обработкой по таймеру, событию...

>Вы написали, что пишите приложение, которое будет шпионить за действиями пользователя ( >вести лог) и далее описали какие данные хотите видеть в этом логе.
>id source <tabulation> datetime stamp <tabulation> message

не пришьете :)
а если без шуток, это лучше сказать "история" (лог) ПРЕДМЕТНОЙ области - ближайшая аналогии: история пользовaтеля (по ИД) в Call-центре, история переписки Instant Messaging и т.п.

> message - это и есть я так понимаю описание действий пользователя.. названия
> кнопок,вводимый текст... координаты мышки...

нет, текстовка поступаемая на один из каналов аппликухи - к-рую надобно локально расположить "наиправильнейшим" образом для приложения

> теперь оказалось, что "message" у вас оказывается многострочный...и судя по упорному желанию
> определить их длинну- то чуть ли не бинарный. Да, с бинарным
> содержимым message конечно плантекстовому файлу будет непросто...

message - многострочный текст ( UTF-8 )

> если вы далее с этими логами (это же логи, не база данных)
> планируете что-то делать вроде парсинга и извлечения из них данных, полнотекстового
> поиска по ним... это совершенно другая задача...
> и лучше сразу засовывать логи в нечто-базоподобное....xml например.или просто в базу...встроенную
> напрмиер..чтото вроде sqlite

в том-то печаль, по Т3 СУБД использовать нельзя, а использумеая библиотека XML сильно не равнодушна к памяти...

> То есть вопрос вобщем то простой:
> вы хотите обеспечить в этой программе логирование (воспользовавшись готовыми отлаженными
> механизмами) или хотите под предлогом этой работы изобрести свою собственную файл-ориентированную
> базу данных.

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

> На мой взгляд - это совершенно разные задачи :)

согласен

В любом случае, придется два варианта на стенде погонять: на файлухе и XML

p.s.:
приблизительная статистика по предметке:

user -> app ( read by 'id source'(90%), 'time stamp'(9%), 'text'(0.999%); delete by 'id source'(0.001 %) )
source -> app ( 100 % insert data )

>> То есть вопрос вобщем то простой:
>> вы хотите обеспечить в этой программе логирование (воспользовавшись готовыми отлаженными
>> механизмами) или хотите под предлогом этой работы изобрести свою собственную файл-ориентированную
>> базу данных.
> повторюсь:
> вообщем с одной стороны надо заложить какой-то базис для расширения,
> с другой не охотa двухколесную промышленность развивать.

Почитайте книжку "Искусство программирования для Unix" Эрик C. Реймонд.
Там такие вещи рассказаны.

> Почитайте книжку "Искусство программирования для Unix" Эрик C. Реймонд.
> Там такие вещи рассказаны.

Благодарствуем, заодно освежим память.