Где программам хранить настройки? / Where to store settings?

User avatar
Eugene Gorbunoff
Site Admin
Posts: 685
Joined: Sat Apr 09, 2005 11:18
Location: St.Petersburg, Russia

Где программам хранить настройки? / Where to store settings?

Postby Eugene Gorbunoff » Mon Feb 21, 2011 14:59

e-co:

(RUS) Как отделить данные пользователей от самих программ? Где программам хранить настройки? Как упростить миграцию при переходе из старой версии ОС на новую? (и сохранить все настройки программ)


(ENG) Short:
* Mac - user's data, settings are separated from applications
* Windows - Windows system directories are separated from dirs for user.
* eComStation - full freedom.. (anarchy)

Question: where to store settings? How the users can collect all settings, data from old eCS system and migrate to eCS 3.0 ?



Read more:

eCo Labs task: http://ecomstation.ru/ecolabs/589-Migrate2020.html

Review: http://ru.ecomstation.ru/showarticle.php?id=226

User avatar
Eugene Gorbunoff
Site Admin
Posts: 685
Joined: Sat Apr 09, 2005 11:18
Location: St.Petersburg, Russia

Re: Где программам хранить настройки? / Where to store settings?

Postby Eugene Gorbunoff » Mon Feb 21, 2011 15:00

2010/11, 2010/12


[16:07:43] <ecoshop> надо как-то настройки так хранить,
[16:07:48] <ecoshop> чтобы при переезде на новую версию ОС
[16:07:55] <ecoshop> их можно легко скопировать
[16:13:10] <Capricorn> Да
[16:13:10] <Capricorn> А разве сейчас они так не хранятся?
[16:26:32] <ecoshop> а где они хранятся?
[16:26:39] <ecoshop> надо какой-то pool
[16:26:51] <ecoshop> все-все программы чтобы хранили в вирт.пуле
[16:26:59] <ecoshop> и когда юзер хочет перейти на eCS 3.0,
[16:27:06] <ecoshop> просто забирает этот pool на новый компутер.
[16:27:17] <ecoshop> вот давай опробуем этот механизм на vkeyb?
[16:29:47] <Capricorn> Давай


[16:30:19] <ecoshop> например, хранить все настройки в
[16:30:33] <Capricorn> Я лишь имел в виду, что настройки можно сохранить, а затем загрузить.
[16:30:41] <ecoshop> mptn\etc\global-settings\vkeyb\*
[16:30:53] <ecoshop> т.е. импорт-экспорт?
[16:31:01] <ecoshop> а тут проблему - долго обходить
[16:31:06] <ecoshop> по каждой программе..
[16:31:16] <ecoshop> надо чтобы они изначально где-то хранилось
[16:31:34] <ecoshop> или чтобы можно было вызвать скрипт для каждой программы установленной.
[16:31:44] <ecoshop> вызываеть его будет спец.программа - она пройдет по всем 50 прогам.
[16:31:52] <ecoshop> только как она знает, какие программы в системе?
[16:32:24] <Capricorn> Гм!


[16:32:31] <ecoshop> потому и предлагаю хранить в .. mptn\etc\global-settings\названиепрограммы\*
[16:32:59] <Capricorn> Ок
[16:33:08] <ecoshop> а почему я мучаюсь?
[16:33:11] <ecoshop> вот Piano..
[16:33:34] <ecoshop> надо было так:
[16:33:44] <ecoshop> экспорт *названий* объектов и программ
[16:34:05] <ecoshop> а при восстановлении  - искать программы/объекты по имени.
[16:34:19] <ecoshop> а что сейчас?
[16:34:23] <ecoshop> юзер пользовался Piano
[16:34:27] <ecoshop> перешел на eCS 2.0
[16:34:33] <ecoshop> а сил установить и настроить Piano нету :(



[17:55:22] <Capricorn> По-моему, то, что ты говоришь - идеологически неверно.
[18:04:01] <ecoshop> ну вот os/2 неудобная.. потому что примитивная.
[18:04:11] <ecoshop> вот и предлагаю модернизировать.
[18:05:32] <ecoshop> а ты меня на карте видишь? :)
[18:05:37] <Capricorn> Для удобного апгреейда в OS/2 уже есть готовый механизм. Зачем изобретать велосипед?
[18:06:02] <ecoshop> а что там за механизм? что-то никому не удается проапгрейдится :)
[18:06:50] <ecoshop> http://ru.ecomstation.ru/poll.php?action=show&id=20
[18:08:07] <Capricorn> Дык проблема в том, что он сломан. Дык, надо чинить его!
[18:08:17] <ecoshop> никак не удается..
[18:08:25] <ecoshop> в том то и дело,
[18:08:31] <Capricorn> Зачем новое что-то изобретать?
[18:08:35] <ecoshop> что у юзеров часто система полурабочая
[18:08:50] <ecoshop> они гребут до новой версии. ставят свежую заново.
[18:08:56] <Capricorn> Чтобы потом все программы переделывать?
[18:08:56] <ecoshop> на новый винчестер. на новый компьютер.
[18:09:10] <ecoshop> т.е. про апгрейд  - я понял. но люди чаще ставят сситему заново.
[18:09:22] <ecoshop> вот для чего я про pool настроект программ говорю
[18:09:46] <ecoshop> надо переделеать 10 программ, затем другие разработчики подтянутся.

[18:15:06] <Capricorn> А куда тогда девать инишники осевые?

User avatar
Eugene Gorbunoff
Site Admin
Posts: 685
Joined: Sat Apr 09, 2005 11:18
Location: St.Petersburg, Russia

Re: Где программам хранить настройки? / Where to store settings?

Postby Eugene Gorbunoff » Mon Feb 21, 2011 15:01

2011/02/21


<|e-co|Shuttle> вот программа. она хранит настройки.
<|e-co|Shuttle> юзер решил перейти на след.версию ОС.
<|e-co|Shuttle> как ему быстро забрать все настройки, все конфиги?
<ElectroDog> |e-co|Shuttle: там одна инишка
<|e-co|Shuttle> как это всё организовать?
<|e-co|Shuttle> вариант 1: утилита, которая знает про каждую программу и собирает о них данные
<|e-co|Shuttle> Вариант 2: все программы юзают функции SaveConfig(), LoadConfig()
<|e-co|Shuttle> а все данные хранятся в одном месте
<|e-co|Shuttle> Вариант 3: QueryConfigPool() - запросить место, где хранить все свои настройки
<ElectroDog> |e-co|Shuttle: сложно. Вариант 2 - собственно и был задуман изначально. Т.е. HINI_USER - был для программ. Но
всем не понравилось, и начали делать INI в каталогах программ.
<ElectroDog> |e-co|Shuttle: мотиватор - как раз то проще переезжать. Скопировал каталог с программой - и ок.
<|e-co|Shuttle> вариант 3 - не приживется.
<ElectroDog> |e-co|Shuttle: угу
<ElectroDog> |e-co|Shuttle: предложение такое - программа - которая "знает" про другие программы. И способ для новых програм
- описать где у них что. Хотя тоже сложно... не все программы можно перенсти простым копированием.
<ElectroDog> |e-co|Shuttle: а как быть с wps папками и другими объектами и классами?
<ElectroDog> |e-co|Shuttle: не знаю, красиво не решить

User avatar
Eugene Gorbunoff
Site Admin
Posts: 685
Joined: Sat Apr 09, 2005 11:18
Location: St.Petersburg, Russia

Re: Где программам хранить настройки? / Where to store settings?

Postby Eugene Gorbunoff » Mon Feb 21, 2011 20:11

Mentore Siesto

What settings are you talking about?

The entire systems lays upon OS2.INI and OS2SYS.INI.


Guidelines from IBM (and developers/users experience) suggest to leave them free from applications data, except for file associations and similar things (i.e. PMView Pro associations, WPS templates and the like).

OS/2 has a powerful Prf* API which allows any PM application to have a separate settings file. The best thing to do is IMHO keeping configuration files into the very same
directory of the program it refers to.

Results are:
- OS/2 INI files are smaller and cleaner, less error-prone
- "any" program can be copied/cloned between one system and another, and it can work flawlessly provided settings are changed (well, not really any program, it depends on many things)
- Uninstalling a program could be a question of simply deleting it (it depends on the program and how does it interact with WPS)

The way to go IMHO is: any program has its configuration files in its directory. UNIX applications use the HOME directory, and it's ought to be so if we want to use them without a
complete rewrite. But UNIX program don't use the Prf API.

So, any *native* OS/2 application should have its configuration files into its installation directory, imho.

User avatar
Eugene Gorbunoff
Site Admin
Posts: 685
Joined: Sat Apr 09, 2005 11:18
Location: St.Petersburg, Russia

Re: Где программам хранить настройки? / Where to store settings?

Postby Eugene Gorbunoff » Mon Feb 21, 2011 20:12

GG|W:

Other food for thoughts WRT " Where to store settings?"
Java uses the %home% env var, but some applications are insisting on creating "Documents and Settings\..." "Appication Data\..." trees (some Qt applications as well)
I am sure we could mimic the Windows (same goes for Unix/Linux) All Users/Current User/Default User trees concepts and provide the relevant tree under eComStation (/users/common | /Users/%username% | /users/default) with the relevant environment variables -- if they already exist, we have to find an easy way to find this information. Even if eCS is mono-user OS we can sort of use it as if it was a multi-user OS (using netdrive and maybe with a reboot).

User avatar
Eugene Gorbunoff
Site Admin
Posts: 685
Joined: Sat Apr 09, 2005 11:18
Location: St.Petersburg, Russia

Re: Где программам хранить настройки? / Where to store settings?

Postby Eugene Gorbunoff » Tue Feb 22, 2011 15:31

Mentore:

> Eugene:
> thank you for detailed explanation.
> >Do you agree that it's difficult migrate to new eCS if all settings
> >are stored in different directories?

Let me ask one question: why should it be difficult?

In a PM program, settings location is / must be transparent to the user. As an user, I don't have to know where my settings file is... It's a developer responsability to know issues related to settings location and potential troubles (file corruption / deletion, directory moved to another drive/location, etc.).

The user must know how to change program settings, but he doesn't have to know where are they, imho.

User avatar
Eugene Gorbunoff
Site Admin
Posts: 685
Joined: Sat Apr 09, 2005 11:18
Location: St.Petersburg, Russia

Re: Где программам хранить настройки? / Where to store settings?

Postby Eugene Gorbunoff » Tue Feb 22, 2011 15:31

Todd:

I also agree that the individual apps need the own space for storing settings and data. But I do however think their should be a central database of the installed applications like the WarpIN database which we already have. I do also think that maybe we need to have an alternate way to list other apps maybe into the WarpIN database for continued notes or manually added / installed apps and maybe a simple comment / note field that can be appended and reviewed by the admin.

I recently worked on a project and developed a toolset that replaced OS2 and OS2SYS ini and other configuration files when the OS/2 Warp 4 workstations were powered off and then back on to find the workstation completely non-functional. The computers were powered off because of an appearant application lock and that was the taught procedure for nearly 600 systems used in daily production for my client across North America. Powering off was the wrong answer to solve the problem, but it was what it was. Of course I recommended a different course of action to the client. The OS2 and OS2SYS ini files were indiscriminately trashed over and over when the users powered off the workstations. The ini recovery / re-build tools the client had just did not cut it for recovery. IMHO these ini files need not be used for central application information until a better toolset / procedure can better recover from problems like I encountered.


Return to “Developers / Разработчики”

Who is online

Users browsing this forum: No registered users and 1 guest

cron