[Alg] Nieuwe manier voor dataopslag*

[Verwijderd]

In Windows heb je het register, in *nix vaak losse configuratiefiles. Het Windows register is niet optimaal, omdat het te log en te groot is. De losse *nix configuratiefiles zijn niet optimaal omdat er geen centrale plaats is om ze op te slaan, en vaak een ietwat onduidelijke indeling hebben.

Nu heb ik daar na enig denken een IMNSHO goede oplossing voor bedacht, namelijk de standaard IniDB.

Het gaat hier om een verzameling van losse configuratiefiles (die als INI-files zijn gestructureerd, vandaar de naar IniDB), die volgens een boomstructuur is geordend in een centraal bestand, net als in het register. In dit geval gaat het echter om losse files, die overal kunnen staan maar toch achterhaald kunnen worden.

Voorbeeld van het centraal bestand:

code:

; Central INI DataBase

[General]
LastUpdate=<datum laatste update>
IniDBVersion=<besturingssysteem>,<programmaversie>
ConfigurationID=0

[Classes]
System=C:\ETC\INI\SYSTEM.INI
Applications=%windir%\All Users\Application Data\General\APP.INI

Een voorbeeld van een bestand voor het fictieve programma 123Text:

code:

; INI DataBase for 123Text Word Processor

[General]
LastUpdate=<datum laatste update>
IniDBVersion=<besturingssysteem>,<programmaversie>
ConfigurationID=3

[Classes]
InstalledFonts=C:\PROGRAM FILES\123Text\FONTS\FONTS.INI

[123Text_General]
WindowSizeX=200
WindowSizeY=400

[123Text_RecentList]
Recent0=C:\MY DOCUMENTS\CV.123DOC
Recent1=C:\MY DOCUMENTS\Notes.123DOC

Je zult zien dat de ConfigurationID verschillend is. Dit nummer staat voor een ``configuration instance''. Bij de Centrale INI Database was dat 0, bij de 123Text INI was dat 3. Dat betekend dat de eerste file de system-wide instellingen bevatte. De tweede file bevatte de instellingen voor User 3, dit kan echter ook Installatie 3 (bij meerdere installaties van hetzelfde programma op een computer) betekenen. Zoals je ziet is het een fluitje van een cent om instellingen van verschillende Users/Instances/Installaties te scheiden. Het programma moet de betekenis van de configuration instances zelf implementeren. Dit kan echter natuurlijk ook ergens in de INI DataBase staan! (en dan b.v. ConfigurationID op 0 zetten)

De sectie [General] bevat de informatie over de INI zelf. Bij [Classes] staan de INI-files die weer meer instellingen kunnen bevatten, zo voorkom je grote INI-files waarin veel gezocht moet worden (wat weer lijkt op een register). De rest van de secties kunnen door het programma zelf willekeurig aan worden gemaakt en gebruikt.

Overbodige INI-files die door onzorgvuldig geschreven programma's achterblijven staan nu dus alleen nog als 1 entry in de hoofddatabase ``Applications''. Zolang die entry niet opgevraagd wordt, wordt het ook niet geladen in het geheugen, zoals bij het Windows register wel gebeurt.

Een entry zou je bijvoorbeeld zo kunnen opvragen:

code:

str RequestedINIFile;
str RequestedValue;

RequestedINIFile = GetINILocation("INI.Applications.WordProcessors.123Text.InstalledFonts");
RequestedValue =  GetINIValue(RequestedINIFile, "Arial.FontType")

Een:

code:

printf(RequestedValue);

zou dus:

code:

TrueType

kunnen opleveren.

Wat vinden jullie ervan?

[ Voor 12% gewijzigd door Verwijderd op 11-04-2005 17:06 . Reden: typo ]

[Verwijderd]

Verwijderd schreef op maandag 11 april 2005 @ 16:40:
In Windows heb je het register, in *nix vaak losse configuratiefiles. Het Windows register is niet optimaal, omdat het te log en te groot is.

Mwa. Het grote nadeel aan het Windows register vind ik dat het niet goed te manipuleren is (al heeft dat er natuurlijk wel mee te maken).

Om het te bewerken heb je alleen de MS Registry Editor, waar je alles in moet pielen. Bij tekstfiles daarentegen, kun je je favoriete teksteditor gebruiken, je kunt kopiëren, knippen, plakken, verplaatsen, kopiëren naar andere directories/computers, in een version control systeem gooien en wat niet al.

Puur vanuit dat oogpunt vind ik files dus al fijner werken.

De losse *nix configuratiefiles zijn niet optimaal omdat er geen centrale plaats is om ze op te slaan

Niet helemaal waar:
• /etc/myprogram.conf voor systeeminstellingen; en
• <HOME>/.myprogram voor gebruikersinstellingen
is toch wel de gangbare standaard.

, en vaak een ietwat onduidelijke indeling hebben.

Sommige applicaties hebben een eigen formaat, dat is waar. Maar het gaat dan vaak om applicaties waarbij het INI formaat moeizaam en omslachtig zou zijn. Triviaal voorbeeld: Apache. Maar er zijn genoeg programma's op *nix die ook gewoon een INI-file achtig formaat gebruiken hoor.

... heel verhaal...
Wat vinden jullie ervan?

Een beetje omslachtig. Vooral de manipulatie zie ik weer lastig worden (zelfde probleem als bij de Windows Registry), omdat de bestanden allemaal van elkaar afhangen. En de applicaties die deze DB gebruiken moeten de bestanden nog zelf aanmaken (of zelf aangeven waar deze opgeslagen moeten worden). Erg transparant is het dus ook niet -- of gaat dat met een autodetectiemechanisme dat je nog niet beschreven hebt?

[gorgi_19]

Zie trouwens ook [rml][ C++] beste plaats om 'settings' te bewaren bij gebruiker[/rml]

[Soultaker]

Hoe dacht je dit qua rechten van gebruikers te gaan regelen? Ik wil niet dat een andere gebruiker mijn instellingen kan wijzigen. Volgens jouw verhaal moet een applicatie dat zelf maar uitzoeken, maar dat is natuurlijk geen handig uitgangspunt in (bijvoorbeeld) een gedeelde werkomgeving. Verder: hoe werkt profile migration? Ik wil op een ander systeem met hetzelfde profile kunnen werken en met dezelfde instellingen.

Voor deze twee aspecten is het veel logischer om instellingen in de home-directory van een gebruiker te zetten (UNIX of Windows) of in een gebruikerspecifiek onderdeel van het register (Windows). Hoe dacht jij dat op te lossen? Hoe verschilt jouw oplossing van een configuratiebestand per gebruiker?

Verder wordt het Windows register heus niet altijd in het geheel in het geheugen geladen en het is wel even wat efficiënter opgeslagen dan als plain-text bestand. Dat het log en traag is valt dus wel mee.

[Verwijderd]

Verwijderd schreef op maandag 11 april 2005 @ 19:40:
[...]

Mwa. Het grote nadeel aan het Windows register vind ik dat het niet goed te manipuleren is (al heeft dat er natuurlijk wel mee te maken).

Om het te bewerken heb je alleen de MS Registry Editor, waar je alles in moet pielen. Bij tekstfiles daarentegen, kun je je favoriete teksteditor gebruiken, je kunt kopiëren, knippen, plakken, verplaatsen, kopiëren naar andere directories/computers, in een version control systeem gooien en wat niet al.

Puur vanuit dat oogpunt vind ik files dus al fijner werken.

$me ook, dat is een van de redenen om niet alles in 1 grote file te zetten

[...]

Niet helemaal waar:
• /etc/myprogram.conf voor systeeminstellingen; en
• <HOME>/.myprogram voor gebruikersinstellingen
is toch wel de gangbare standaard.

Klopt, maar kijk maar eens naar de verschillende distributies, versies etc. Bovendien, als de locatie/naam van de file verandert, hoef je dat alleen maar in het parent INI op te geven.

[quote]
[...]

Sommige applicaties hebben een eigen formaat, dat is waar. Maar het gaat dan vaak om applicaties waarbij het INI formaat moeizaam en omslachtig zou zijn. Triviaal voorbeeld: Apache. Maar er zijn genoeg programma's op *nix die ook gewoon een INI-file achtig formaat gebruiken hoor.
[/qoute]

Weet ik, maar met IniDB heb je een gestandaardiseert en een uitwisselbaar formaat, dat ook voor andere apps/users makkelijker te bewerken is.

[...]


Een beetje omslachtig. Vooral de manipulatie zie ik weer lastig worden (zelfde probleem als bij de Windows Registry), omdat de bestanden allemaal van elkaar afhangen. En de applicaties die deze DB gebruiken moeten de bestanden nog zelf aanmaken (of zelf aangeven waar deze opgeslagen moeten worden). Erg transparant is het dus ook niet -- of gaat dat met een autodetectiemechanisme dat je nog niet beschreven hebt?

Als je een centrale service library schrijft (en dat ben ik van plan) met Section-level locking, is het geen probleem om de manipulatie te reguleren. Je moet natuurlijk niet een te diepe klassenstructuur maken, behalve als je er een goede reden voor hebt. Bepaalde files (INI.INI, APP.INI, etc) zullen er altijd zijn. Als je data moet sharen over verschillende applicaties, kun je het gewoon aan de centrale service vragen. En zo'n INI aanmaken gaat de setup net zo makkelijk af als iets in het Windows register schrijven. Even een bestand aanmaken, de centrale service aanroepen om het te registreren, en je bent klaar.

[Verwijderd]

Soultaker schreef op maandag 11 april 2005 @ 20:48:
Hoe dacht je dit qua rechten van gebruikers te gaan regelen? Ik wil niet dat een andere gebruiker mijn instellingen kan wijzigen. Volgens jouw verhaal moet een applicatie dat zelf maar uitzoeken, maar dat is natuurlijk geen handig uitgangspunt in (bijvoorbeeld) een gedeelde werkomgeving. Verder: hoe werkt profile migration? Ik wil op een ander systeem met hetzelfde profile kunnen werken en met dezelfde instellingen.

Voor deze twee aspecten is het veel logischer om instellingen in de home-directory van een gebruiker te zetten (UNIX of Windows) of in een gebruikerspecifiek onderdeel van het register (Windows). Hoe dacht jij dat op te lossen? Hoe verschilt jouw oplossing van een configuratiebestand per gebruiker?

Verder wordt het Windows register heus niet altijd in het geheel in het geheugen geladen en het is wel even wat efficiënter opgeslagen dan als plain-text bestand. Dat het log en traag is valt dus wel mee.

De basis is voor elk platform hetzelfde. Windows- en *nix-specifieke instellingen kunnen dan onder INI.Applications.<besturingssysteem> ofzow staan. Door de configuration instances kun je gebruikers makkelijk scheiden. Het besturingssysteem kan de user-specifieke INI files gewoon via de interne rechtenstructuur beveiligen, ze kunnen immers overal staan.

En met hetzelfde profile onder verschillende OS'en gaat prima. Het is niet OS-specifiek, al kunnen er wel OS-specifieke instellingen in worden geplaatst. Die worden dan gewoon door andere OS'en genegeerd.

[Soultaker]

Maar dan heb je dus alsnog ini-files in je homedirectory staan, als ik het goed begrijp? Beargumenteer eens wat jouw systeem dan nog toevoegt? (Overigens had ik het bij migration nog niet echt over het werken onder verschillende besturingssystemen, maar alleen over verschillende systemen die hetzelfde besturingssysteem draaien.)

(Ik lijk misschien overdreven kritisch, maar ik probeer een beetje zwakke punten te vinden. )

[ Voor 29% gewijzigd door Soultaker op 11-04-2005 21:18 ]

[Orphix]

En dit soort problemen zouden dus perfect opgelost kunnen worden via een filesystem dat als database benaderbaar is. Ik vind het zeer jammer dat WinFS niet in longhorn komt, het lijkt mij een heel goed concept.

In dit geval zou je dus bestanden overal kunnen plaatsen; zolang ze de juiste attributen hebben (vb application configfile, user configfile, etc.) kan je er alle kanten mee op. De applicatie kan enkel die configuratiebestanden opvragen voor zichzelf. Het OS kan dmv een andere query snel alle configuratiebestanden op het hele systeem opvragen. Ongeveer het concept wat jij voorstelt.

Verder vind ik je idee best goed, maar wat wil je er precies mee? Als ik het goed begrijp is het een systeem wat ook op OS niveau ingrijpt en dan wordt de implementatie natuurlijk al heel moeilijk.

[Verwijderd]

Soultaker schreef op maandag 11 april 2005 @ 21:17:
Maar dan heb je dus alsnog ini-files in je homedirectory staan, als ik het goed begrijp? Beargumenteer eens wat jouw systeem dan nog toevoegt? (Overigens had ik het bij migration nog niet echt over het werken onder verschillende besturingssystemen, maar alleen over verschillende systemen die hetzelfde besturingssysteem draaien.)

Waarom zouden ze in de Homedir moeten staan? Je kunt ze toch gewoon chown ofzow gebruiken? Bovendien heeft het een in principe oneindig diepe klassenstructuur, zonder alles te moeten doorzoeken. Wil je onderdelen/config files van een programma op een andere locatie opslaan, of het hele programma verplaatsen, hoef je (al dan niet geautomatiseerd) alleen maar de paden te veranderen in het verantwoordelijke INI bestand. Er wordt ook geen overbodige data geladen als dat niet nodig is. Het is een slank en toch uitgebreid systeem. Het is ook makkelijk portable, zowel de code als de INI files zelf. Bovendien kun je alles centraal terugvinden.

(Ik lijk misschien overdreven kritisch, maar ik probeer een beetje zwakke punten te vinden. )

Daar hou ik wel van

[ Voor 1% gewijzigd door Verwijderd op 11-04-2005 21:37 . Reden: Typo ]

[Verwijderd]

Orphix schreef op maandag 11 april 2005 @ 21:34:
En dit soort problemen zouden dus perfect opgelost kunnen worden via een filesystem dat als database benaderbaar is. Ik vind het zeer jammer dat WinFS niet in longhorn komt, het lijkt mij een heel goed concept.

In dit geval zou je dus bestanden overal kunnen plaatsen; zolang ze de juiste attributen hebben (vb application configfile, user configfile, etc.) kan je er alle kanten mee op. De applicatie kan enkel die configuratiebestanden opvragen voor zichzelf. Het OS kan dmv een andere query snel alle configuratiebestanden op het hele systeem opvragen. Ongeveer het concept wat jij voorstelt.

Verder vind ik je idee best goed, maar wat wil je er precies mee? Als ik het goed begrijp is het een systeem wat ook op OS niveau ingrijpt en dan wordt de implementatie natuurlijk al heel moeilijk.

Het is makkelijk om het register/de config files naast de IniDB te laten bestaan, en je apps langzamerhand porten. Het hoeft dus niet op OS niveau te zijn; het is op App niveau prima bruikbaar.

Over WinFS: $me dacht zelf ook al: waarom zou je geen files in die INI's kunnen opslaan? Een serie INI's en een algemene loader en je hebt een compleet DB filesystem

[D4Skunk]

ik weet niet of het .net platform mono dit ondersteunt, maar voor windows bestaat er zoiets als isolated storage ( klik), dit zowel op app -, user-, als libraryniveau.
Het grote voordeel hiervan is dat de usersettings dan ook automatisch dmv roaming profiles meegenomen worden naar andere pc's, dus als ik binnen hetzelfde domein op een andere pc aanlog, krijg ik toch dezelfde settings terug...

[Verwijderd]

Dit kan ook met roaming profiles, gewoon het pad naar het bestand op de server aangeven. Bovendien is dit heel simpel, zonder veel overhead etc., wat .net relatief veel heeft. Ook is dit systeem native cross-platform zonder tussenlagen.

[Soultaker]

Verwijderd schreef op maandag 11 april 2005 @ 21:37:
Waarom zouden ze in de Homedir moeten staan? Je kunt ze toch gewoon chown ofzow gebruiken?

Ja, maar als ze niet in mijn home directory staan, worden ze niet gemigreerd als ik op een ander systeem inlog. (Dat bedoelde ik met het profile migration gebeuren.)

Verder, hoe stel je je dat chown'en voor? Een directory die world writeable is lijkt me absoluut niet handig. Dan moet je dus een proces hebben draaien wat root/Administrator-access heeft en die bestanden aanmaakt. Een nieuwe security risk. En een run-time dependency. Dat allemaal terwijl je de ini-file ook in de home directory had kunnen zetten, zonder verdere eisen.

Een service met extra priviliges moeten draaien betekent ook dat je jouw software nooit als eenvoudige gebruiker kan installeren (in je eigen homedirectory, alleen voor jezelf dus). Dat lijkt me niet wenselijk.

Concreet: wat is het voordeel van jouw systeem boven een applicatie die zijn instellingen in een standaardlocatie (voor globale instellingen) en in de home directories (voor gebruikers) zet? Het is natuurlijk handig dat jouw library een uniform, portable bestandsformaat hanteert met een portable API (wat voor bijvoorbeeld de Windows Registry niet geldt), maar is een simpele library voor het lezen en schrijven van die configuratiebestanden zonder verder gedoe met priviliges en services dan niet veel handiger?

[ Voor 28% gewijzigd door Soultaker op 11-04-2005 23:53 ]

[Onno]

Een algemene API naar een mogelijk systeem-specifieke opslag lijkt me nuttiger. In Java heb je bijvoorbeeld de Preferences API die op Windows je register kan gebruiken en in Unix losse bestanden. Zo kun je toch altijd dezelfde API gebruiken zonder dat je meteen op een andere manier gaat opslaan die niet past binnen het OS dat je gebruikt.

Enigszins off-topic hier, maar ik wil ook nog wel even wat zeggen ter verdediging van het Windows register concept. (ook al gebruik ik dan geen Windows )
Dat het groot en log zou zijn komt door de manier waarop van het register gebruik gemaakt wordt door de diverse toepassingen (van al die GUIDs die Windows overal dumpt word ik helemaal bang..), niet door het systeem zelf. Verder biedt het enkele belangrijke voordelen die veel andere systemen niet hebben, bijvoorbeeld de mogelijkheid om overal ACLs aan te hangen. Binnen de huidige register API is het ook perfect mogelijk om een andere backend te gebruiken voor (gedeeltes) van je register dan lokale bestanden, ook al is dat niet iets wat (voor zover ik weet) ooit gedaan is. Dat is het voordeel van een duidelijke API, en dat is iets waar de threadstarter ook rekening mee zou moeten houden denk ik. Je wilt persistent storage, de opslagmethode is voor applicaties totaal niet relevant en zou volstrekt transparent moeten kunnen worden vervangen door een andere.

[Soultaker]

Onno schreef op dinsdag 12 april 2005 @ 00:40:
Enigszins off-topic hier, maar ik wil ook nog wel even wat zeggen ter verdediging van het Windows register concept. (ook al gebruik ik dan geen Windows )
Dat het groot en log zou zijn komt door de manier waarop van het register gebruik gemaakt wordt door de diverse toepassingen (van al die GUIDs die Windows overal dumpt word ik helemaal bang..), niet door het systeem zelf.

En dan nog valt het best mee. Die paar megabytes kun je best missen en de inhoud zelf is snel beschikbaar. Ik zou niet weten waar het idee vandaan komt dat het een 'log' systeem is. Ja, er staat veel in, maar goed, dat is ook de hele reden om een registry te maken.

Verder biedt het enkele belangrijke voordelen die veel andere systemen niet hebben, bijvoorbeeld de mogelijkheid om overal ACLs aan te hangen.

Dan heb je de functionaliteit die je ook al in je bestandssysteem hebt zitten dus gedupliceert; UNIX-advocates noemen als voordeel van configuratiebestanden juist dat je ze kunt beveiligen, comprimeren, back-upen, kopiëren en openen zoals elk ander bestand. In Windows is zowel de API als de achterliggende implementatie gedupliceert. Accoord, de Windows registry was noodzakelijk om in Windows 9x met FAT32 een fatsoenlijk systeem te krijgen, maar nu zelfs Windows met NTFS (en later WinFS) een modern bestandssysteem heeft (met zelfs support voor file compression en, handig voor databases, sparse files), is het alleen maar jammer dat die geavanceerde functionaliteit niet gebruikt wordt.

Dat is het voordeel van een duidelijke API, en dat is iets waar de threadstarter ook rekening mee zou moeten houden denk ik. Je wilt persistent storage, de opslagmethode is voor applicaties totaal niet relevant en zou volstrekt transparent moeten kunnen worden vervangen door een andere.

Daar ben ik het helemaal mee eens. Natuurlijk wordt die methode wel interessant op het moment dat het een eis is dat de werking transparant is voor de gebruiker (waar staan mijn instellingen?) en je wil dat configuratiebestanden met de hand te bewerken zijn. (Voor de Windows Registry heeft men terecht gekozen dat dat niet nodig is; je gebruikt de registry editor maar om de database te benaderen.)

[ Voor 10% gewijzigd door Soultaker op 12-04-2005 01:12 ]

[Verwijderd]

Soultaker schreef op maandag 11 april 2005 @ 23:50:
[...]

Ja, maar als ze niet in mijn home directory staan, worden ze niet gemigreerd als ik op een ander systeem inlog. (Dat bedoelde ik met het profile migration gebeuren.)

Als de migratiesoftware gewoon in de IniDB kijkt waar de verschillende bestanden van het profiel staan, is dat geen probleem.

Verder, hoe stel je je dat chown'en voor? Een directory die world writeable is lijkt me absoluut niet handig. Dan moet je dus een proces hebben draaien wat root/Administrator-access heeft en die bestanden aanmaakt. Een nieuwe security risk. En een run-time dependency. Dat allemaal terwijl je de ini-file ook in de home directory had kunnen zetten, zonder verdere eisen.

Klopt, maar waar de config files staan is puur de keuze van de gebruiker (lees: installeerder van IniDB), al kan er altijd een locatie gesuggesteerd worden door de install.

Een service met extra priviliges moeten draaien betekent ook dat je jouw software nooit als eenvoudige gebruiker kan installeren (in je eigen homedirectory, alleen voor jezelf dus). Dat lijkt me niet wenselijk.

De centrale service kan ook gewoon in user-space draaien als dat nodig is.

Concreet: wat is het voordeel van jouw systeem boven een applicatie die zijn instellingen in een standaardlocatie (voor globale instellingen) en in de home directories (voor gebruikers) zet? Het is natuurlijk handig dat jouw library een uniform, portable bestandsformaat hanteert met een portable API (wat voor bijvoorbeeld de Windows Registry niet geldt), maar is een simpele library voor het lezen en schrijven van die configuratiebestanden zonder verder gedoe met priviliges en services dan niet veel handiger?

De service komt er alleen bij/tussen als het veelgebruikte bestanden zijn. De rest kan gewoon door een simpele lib gedaan worden.

[FendtVario]

Wat ik wel een aardig idee vind is dat je de ini bestanden terug kan vinden. Dit kan soms handig zijn, maar als je dit voorziet kun je ook de ini's in een daarvoor aangewezen (vaste) map zetten die je met een functie aanreop in je eigen vaste bibliotheken kan achterhalen.

Het draaien van een extra service geeft inderdaad nadelen, zoals Soultaker al aangeeft, installaties worden moeilijker en wijzigingen in het systeem hebben misschien een grotere impact dan je nu verwacht. En als ook de kleine applicaties deze service nodig hebben maak je misschien wel te veel overhead.

[Onno]

Soultaker schreef op dinsdag 12 april 2005 @ 01:11:
Dan heb je de functionaliteit die je ook al in je bestandssysteem hebt zitten dus gedupliceert; UNIX-advocates noemen als voordeel van configuratiebestanden juist dat je ze kunt beveiligen, comprimeren, back-upen, kopiëren en openen zoals elk ander bestand. In Windows is zowel de API als de achterliggende implementatie gedupliceert.

Rechten op een bestandssysteem zijn veel minder fijnmazig, en al helemaal in Unix. Tenzij je voor elke waarde een apart bestandje gaat maken kun je niet bereiken wat je nu met het register kunt, maar in dat geval vraag ik me af hoe efficient dat nog is. De overige punten, dat je ze zomaar kunt backuppen, enz. kan natuurlijk wel een voordeel zijn. Alhoewel je met allemaal losse bestanden niet noodzakelijk een consistente backup krijgt, het kan zijn dat een bestand al aangepast is terwijl een volgende die daar afhankelijk van is dat nog moet worden. Ik geloof dat ik ook graag transacties in settingsystemen zou willen hebben. En eigenlijk sowieso alle ACID eigenschappen.

[Verwijderd]

Ik mis eigelijk een nette manier van geneste attributen. En dat vind ik persoonlijk het mooie aan xml, waar ik dus zelf een groot voorstander van ben. Ik zou zeggen ontwerp een goede "scheme" voor een generieke manier van het opslaan van config bestanden, dat je zoiets krijgt:

code:

<attribute name="timeout" mandetory="true">
  <value>100</value>
  <description>The timeout of bla bla in milliseconds</description>
  <default-value>1000</default-value>
</attribute>

(uiteraard is dit geen voorbeeld van geneste attributen...)

Zodoende kunt je ook gewoon een standaard tools ontwikkelen die willekeurige configuratie bestanden kunnen wijzigen.

[ Voor 14% gewijzigd door Verwijderd op 12-04-2005 11:49 ]

[Verwijderd]

FendtVario schreef op dinsdag 12 april 2005 @ 08:18:
Wat ik wel een aardig idee vind is dat je de ini bestanden terug kan vinden. Dit kan soms handig zijn, maar als je dit voorziet kun je ook de ini's in een daarvoor aangewezen (vaste) map zetten die je met een functie aanreop in je eigen vaste bibliotheken kan achterhalen.

Het draaien van een extra service geeft inderdaad nadelen, zoals Soultaker al aangeeft, installaties worden moeilijker en wijzigingen in het systeem hebben misschien een grotere impact dan je nu verwacht. En als ook de kleine applicaties deze service nodig hebben maak je misschien wel te veel overhead.

Die service is gewoon een programma dat alleen aangeroepen wordt als het nodig is (kan natuurlijk wel gecached worden). Bovendien geldt die service alleen voor de veelgebruikte bestanden. Misschien moet ik maar eens denken aan een soort logger die registreert welke bestanden het meest gebruikt worden (standaard natuurlijk ook INI.INI, APP.INI, etc) en die automatisch aan de service/cache toevoegt. De IniDB API kijkt gewoon of het INI-bestand in de service/cache lijst staat en bepaalt aan de hand daarvan of het een ``gewone'' access methode of de service moet gebruiken. De service is dan ook niet verplicht; het kan handig zijn, maar je kunt best zonder.

[Verwijderd]

Onno schreef op dinsdag 12 april 2005 @ 10:31:
[...]

Rechten op een bestandssysteem zijn veel minder fijnmazig, en al helemaal in Unix. Tenzij je voor elke waarde een apart bestandje gaat maken kun je niet bereiken wat je nu met het register kunt, maar in dat geval vraag ik me af hoe efficient dat nog is. De overige punten, dat je ze zomaar kunt backuppen, enz. kan natuurlijk wel een voordeel zijn. Alhoewel je met allemaal losse bestanden niet noodzakelijk een consistente backup krijgt, het kan zijn dat een bestand al aangepast is terwijl een volgende die daar afhankelijk van is dat nog moet worden. Ik geloof dat ik ook graag transacties in settingsystemen zou willen hebben. En eigenlijk sowieso alle ACID eigenschappen.

Elke APP/deel van een (grote, anders heeft het geen zin) APP kan gewoon een per-user config aanmaken. Gewoon de API call een ConfigurationID meegeven die per user verschilt. Dan kun je makkelijk instellingen groeperen. Bovendien, je zou in principe een progje kunnen schrijven dat een consistente backup maakt. Ook kun je configuratiebestanden kopieren/backuppen als niets er gebruik van maakt. De hele tree hoeft niet mee, alleen het specifieke bestand. Even opnieuw in de parent INI een verwijzing aanmaken (importeren zo je wilt) en alles werkt weer. Dit zou ook automatisch kunnen.

[4VAlien]

In principe houdt niemand je tegen om een XML wrapper voor het windows registry te schrijven. Mbv Xpath kan je ook in een monolitische file snel dingen zoeken. Maar vooral bij windows is een (binair) dedicated stuk file handiger ivm de grootte en verwerkingssnelheid.

[Onno]

Verwijderd schreef op dinsdag 12 april 2005 @ 15:04:
Elke APP/deel van een (grote, anders heeft het geen zin) APP kan gewoon een per-user config aanmaken. Gewoon de API call een ConfigurationID meegeven die per user verschilt.

Is weer extra werk, en dat wil je niet. (ik niet in ieder geval ) Daarnaast kun je je afvragen of het wel zo eenvoudig is om een uniek ID per gebruiker te bedenken. Hoe wil je dat eigenlijk doen?

Overigens zie ik niet helemaal wat dat te maken heeft met wat ik zei.

Dan kun je makkelijk instellingen groeperen. Bovendien, je zou in principe een progje kunnen schrijven dat een consistente backup maakt.

Hoe dan? Hoe voorkom je dat je nooit toevallig een backup maakt op het moment dat setting A net geupdate is maar B nog niet? Je kunt met file-based locking werken, maar dat gaat alleen maar goed voor wijzigingen die niet meer dan een bestand aangaan, en dat hoeft niet altijd het geval te zijn.

[ Voor 10% gewijzigd door Onno op 12-04-2005 15:15 ]

[Verwijderd]

Verwijderd schreef op dinsdag 12 april 2005 @ 11:49:
Ik mis eigelijk een nette manier van geneste attributen. En dat vind ik persoonlijk het mooie aan xml, waar ik dus zelf een groot voorstander van ben. Ik zou zeggen ontwerp een goede "scheme" voor een generieke manier van het opslaan van config bestanden, dat je zoiets krijgt:

code:

<attribute name="timeout" mandetory="true">
  <value>100</value>
  <description>The timeout of bla bla in milliseconds</description>
  <default-value>1000</default-value>
</attribute>

(uiteraard is dit geen voorbeeld van geneste attributen...)

Zodoende kunt je ook gewoon een standaard tools ontwikkelen die willekeurige configuratie bestanden kunnen wijzigen.

Idd. dat zou op een hoger niveau (bovenop de bare INI API) kunnen gebeuren. Niets weerhoudt je ervan om een XML entry in een INI op te nemen.

Zoiets als dit:

code:

<ini headers etc.>

[XML_Entry_Foo]
EntryNumLines=2
EntryLine0=<attribute name="Foo">
EntryLine1= <value>100</value>
EntryLine2=</attribute>

[XML_Entry_Bar]
EntryNumLines=1
EntryLine0=<attribute name="Bar">
EntryLine1=</attribute>

[Verwijderd]

4VAlien schreef op dinsdag 12 april 2005 @ 15:05:
In principe houdt niemand je tegen om een XML wrapper voor het windows registry te schrijven. Mbv Xpath kan je ook in een monolitische file snel dingen zoeken. Maar vooral bij windows is een (binair) dedicated stuk file handiger ivm de grootte en verwerkingssnelheid.

Idd, maar dat is weer niet zo goed portable

[Verwijderd]

SqlLite

[Onno]

Verwijderd schreef op dinsdag 12 april 2005 @ 15:14:
Niets weerhoudt je ervan om een XML entry in een INI op te nemen.

Zoiets als dit:

code:

<ini headers etc.>

[XML_Entry_Foo]
EntryNumLines=2
EntryLine0=<attribute name="Foo">
EntryLine1= <value>100</value>
EntryLine2=</attribute>

[XML_Entry_Bar]
EntryNumLines=1
EntryLine0=<attribute name="Bar">
EntryLine1=</attribute>

Daar geef je meteen nog een beperking van .ini bestanden: je kunt niet alle soorten whitespace zomaar gebruiken (of uberhaupt alle tekens)

Iets als XML heeft duidelijke tekenset en escaping mechanismen zodat je alles op een niet ambigue manier kunt opslaan, daar zul je bij .ini bestanden als applicatie zelf wat voor moeten verzinnen.

[FendtVario]

Verwijderd schreef op dinsdag 12 april 2005 @ 14:57:
Die service is gewoon een programma dat alleen aangeroepen wordt als het nodig is (kan natuurlijk wel gecached worden). Bovendien geldt die service alleen voor de veelgebruikte bestanden. .... De IniDB API kijkt gewoon of het INI-bestand in de service/cache lijst staat en bepaalt aan de hand daarvan of het een ``gewone'' access methode of de service moet gebruiken. De service is dan ook niet verplicht; het kan handig zijn, maar je kunt best zonder.

En wie beslist er of die service aangeroepen moet worden? Neem je in het IniDB component voor de applicatie dan beide delen op, om de service aan te spreken en om zelf het bestand te lezen? Het lijkt mij niet handig als je het ene bestand wel via je service benaderd en een op een dieper niveau niet. Stel dat het bestand op niveau 2x zoveel gebruikt wordt als het bestand een niveau hoger maar je benaderd het niet via de service. Wie houdt dat bij en wanneer ga je over tot caching. Het lijkt mij meer iets van altijd via de service of nooit.

[Verwijderd]

Verwijderd schreef op dinsdag 12 april 2005 @ 15:14:
Idd. dat zou op een hoger niveau (bovenop de bare INI API) kunnen gebeuren. Niets weerhoudt je ervan om een XML entry in een INI op te nemen.

Daarbij heb ik het bezwaar dat je configuratie bestanden niet meer generiek zijn. Het is lastig om extra informatie (meta data) over een bepaalde property op te slaan. Zodoende kun je geen gebruik maken van tools die je configuratie bestand inlezen en wijzigen met de nodige informatie.

Zoals je nu vooral ziet in de linux wereld is het volgooien van commentaar van een configuratie bestand. Maak daar vaste velden voor en je kent het op een nette manier grafisch weergeven. Daar leent xml zich domweg veel beter voor dan een plat ini bestand. Snelheid interesseert me niet en zou ook niet interressant mogen zijn. Een configuratie bestand is immers niet bedoeld om continu te veranderen, tijdens een normale sessie dient deze enkel gelezen te worden tijdens het starten van de applicatie.
Snelheids winst behaal je door caching...

[Verwijderd]

Onno schreef op dinsdag 12 april 2005 @ 15:13:
[...]

Is weer extra werk, en dat wil je niet. (ik niet in ieder geval ) Daarnaast kun je je afvragen of het wel zo eenvoudig is om een uniek ID per gebruiker te bedenken. Hoe wil je dat eigenlijk doen?

Overigens zie ik niet helemaal wat dat te maken heeft met wat ik zei.

Waarom zou je daar geen mogelijkheid voor kunnen toevoegen in de API. Het gebruikersID is simpel: De eerste gebruiker die aangemaakt wordt is 1 de 2e 2, etc. (0 is voor algemeen/system-wide). De ConfigurationID's zijn eigenlijk ook een soort Access-control lists.

[...]

Hoe dan? Hoe voorkom je dat je nooit toevallig een backup maakt op het moment dat setting A net geupdate is maar B nog niet? Je kunt met file-based locking werken, maar dat gaat alleen maar goed voor wijzigingen die niet meer dan een bestand aangaan, en dat hoeft niet altijd het geval te zijn.

En als dat nu in het register gebeurt? Dan heb je ook geen consistente backup. Of je nu de service (voor veel gebruikte INI files) of de ``gewone'' manier gebruikt, er komt altijd een lock-iets te staan voor alle bestanden die het aangaan. Dat ``iets'' hoeft geen bestand te zijn, het kan gewoon een gedeeld stukje geheugen zijn. Op mijn DOS systemen gebruik ik files op een kleine ramdisk Zodra de bestanden zijn aangepast, verdwijnen ze allemaal pas. De API gebruikt dan ook een soort wachtrij die je als je klaar bent moet afhandelen zoals bijvoorbeeld:

code:

OpenINIQueue();
SetINILocation("INI.Applications.WordProcessors.123Text.InstalledFonts);
SetINIValue("Arial.FontType", "TrueType");
DispatchINIValue();
SetINILocation("INI.Applications.WordProcessors.123Text");
SetINIValue("123Text_General.WindowSizeX", "800");
DispatchINIValue();
SetINIValue("123Text_General.WindowSizeY" "600");
DispatchINIValue();
DispatchINIQueue();

Als je maar 1 value hoeft te veranderen kun je gewoon een API call aanroepen die dit automatisch doet.

[Verwijderd]

FendtVario schreef op dinsdag 12 april 2005 @ 15:23:
[...]


En wie beslist er of die service aangeroepen moet worden? Neem je in het IniDB component voor de applicatie dan beide delen op, om de service aan te spreken en om zelf het bestand te lezen? Het lijkt mij niet handig als je het ene bestand wel via je service benaderd en een op een dieper niveau niet. Stel dat het bestand op niveau 2x zoveel gebruikt wordt als het bestand een niveau hoger maar je benaderd het niet via de service. Wie houdt dat bij en wanneer ga je over tot caching. Het lijkt mij meer iets van altijd via de service of nooit.

Veelgebruikte INI files komen in een aparte lijst te staan. Als de benodigde INI daarin staat, gaat het via de service. Die service maakt eigenlijk niet deel uit van de reference IniDB API, maar _kan_ geimplementeerd worden. Bij DOS of andere slomere/simpelere systemen heeft het weinig zin om een service te gebruiken. Wat efficienter is weet ik niet. Dat zal in de praktijk moeten blijken.

[Verwijderd]

Verwijderd schreef op dinsdag 12 april 2005 @ 15:25:
[...]

Daarbij heb ik het bezwaar dat je configuratie bestanden niet meer generiek zijn. Het is lastig om extra informatie (meta data) over een bepaalde property op te slaan. Zodoende kun je geen gebruik maken van tools die je configuratie bestand inlezen en wijzigen met de nodige informatie.

Zoals je nu vooral ziet in de linux wereld is het volgooien van commentaar van een configuratie bestand. Maak daar vaste velden voor en je kent het op een nette manier grafisch weergeven. Daar leent xml zich domweg veel beter voor dan een plat ini bestand. Snelheid interesseert me niet en zou ook niet interressant mogen zijn. Een configuratie bestand is immers niet bedoeld om continu te veranderen, tijdens een normale sessie dient deze enkel gelezen te worden tijdens het starten van de applicatie.
Snelheids winst behaal je door caching...

Wat ik bedoel is een soort embedded XML file. Die wordt door een hogere laag dan de IniDB API ingelezen en afgehandeld. De API heeft op deze manier veel uitbreidingsmogelijkheden, zoals het eerder genoemde DataBase FileSystem.

[Onno]

Verwijderd schreef op dinsdag 12 april 2005 @ 15:43:
Waarom zou je daar geen mogelijkheid voor kunnen toevoegen in de API. Het gebruikersID is simpel: De eerste gebruiker die aangemaakt wordt is 1 de 2e 2, etc. (0 is voor algemeen/system-wide). De ConfigurationID's zijn eigenlijk ook een soort Access-control lists.

Dan nog moet je op de een of andere manier bijhouden welke user bij welk ID hoort. Gebruikersnaam lijkt leuk, maar die kan gewoon veranderen en dan is je mapping stuk.

En als dat nu in het register gebeurt? Dan heb je ook geen consistente backup.

Klopt, ik heb ook niet gezegd dat het register daar wel in voorziet. Maar het is wel iets wat ik verwacht van een systeem dat beter moet zijn dan wat er nu beschikbaar is.

Of je nu de service (voor veel gebruikte INI files) of de ``gewone'' manier gebruikt, er komt altijd een lock-iets te staan voor alle bestanden die het aangaan. Dat ``iets'' hoeft geen bestand te zijn, het kan gewoon een gedeeld stukje geheugen zijn. Op mijn DOS systemen gebruik ik files op een kleine ramdisk Zodra de bestanden zijn aangepast, verdwijnen ze allemaal pas.

Dat is mooi, maar ze moeten ook tegelijk verschijnen. En dat is lastiger. Stel je immers voor dat programma A begint bestand X aan te passen, terwijl programma B met bestand Y bezig is. Dat mag gewoon. Maar nu wil A in dezelfde batch ook Y aanpassen.. wat doe je dan? En daar bovenop wil B zelfs misschien nog wel wat met X doen.

[Verwijderd]

Onno schreef op dinsdag 12 april 2005 @ 15:54:
[...]

Dan nog moet je op de een of andere manier bijhouden welke user bij welk ID hoort. Gebruikersnaam lijkt leuk, maar die kan gewoon veranderen en dan is je mapping stuk.

Hetzelfde als Windows of *nix: gewoon het rauwe UID

[...]

Klopt, ik heb ook niet gezegd dat het register daar wel in voorziet. Maar het is wel iets wat ik verwacht van een systeem dat beter moet zijn dan wat er nu beschikbaar is.

Ik ook

[...]

Dat is mooi, maar ze moeten ook tegelijk verschijnen. En dat is lastiger. Stel je immers voor dat programma A begint bestand X aan te passen, terwijl programma B met bestand Y bezig is. Dat mag gewoon. Maar nu wil A in dezelfde batch ook Y aanpassen.. wat doe je dan? En daar bovenop wil B zelfs misschien nog wel wat met X doen.

,
Hij lockt eerst _alle_ gebruikte bestanden. Zodra dat gelukt is, verandert hij de waarden 1 voor 1. Dan verwijderd hij de locks pas.

[Onno]

Verwijderd schreef op dinsdag 12 april 2005 @ 16:05:
Hetzelfde als Windows of *nix: gewoon het rauwe UID

En dan heb je in feite dus helemaal geen mapping meer nodig, dan zou je direct het OS-specifieke ID kunnen gebruiken, met daarbij een andere manier om globale instellingen aan te geven. (want id=0 voldoet dan niet meer)

Hij lockt eerst _alle_ gebruikte bestanden. Zodra dat gelukt is, verandert hij de waarden 1 voor 1. Dan verwijderd hij de locks pas.

Maar dat is ook onhandig. Dan kan je update-request dus na een ander update-request uitgevoerd worden, waardoor je eigenlijk met waarden zat te werken die al niet meer actueel zijn.

Wat ik aan probeer te geven: een goede allesomvattende structuur is lang niet zo simpel als je in je startpost doet vermoeden. Er komt heel wat meer bij kijken dan alleen simpele .ini-bestandjes, als je het echt goed wilt maken. En dan is er nog de vraag of .ini-bestanden wel zo'n goede basis zijn. Ik zou zeggen van niet. Zelfde voor het concept van ConfigurationIDs. Een bestand in de homedirectory van de user zetten voor een user-specifieke versie is gewoon veel eenvoudiger en net zo effectief.

Je huidige opzet lijkt me te bewerkelijk om praktisch te zijn, zonder echt duidelijke voordelen.

[Verwijderd]

Onno schreef op dinsdag 12 april 2005 @ 16:47:
[...]

En dan heb je in feite dus helemaal geen mapping meer nodig, dan zou je direct het OS-specifieke ID kunnen gebruiken, met daarbij een andere manier om globale instellingen aan te geven. (want id=0 voldoet dan niet meer)

Dat ID kan gewoon in de value ConfigurationID staan. En je kunt ook een global settings INI maken met een andere aanduiding voor global.

[...]

Maar dat is ook onhandig. Dan kan je update-request dus na een ander update-request uitgevoerd worden, waardoor je eigenlijk met waarden zat te werken die al niet meer actueel zijn.

Als je 1 instelling door meerdere onderdelen van progjes wilt laten veranderen, zorg je er toch voor dat je goede sync tussen de 2 hebt? Het is onzinnig om dezelfde waarde door 2 apart ontwikkelde programma's constant te laten veranderen. Voor zeer algemene files heb je de service, die ook voor uitlezen gebruikt kan worden, net zoals in het Windows register. IniDB is niet voor IPC, maar voor relatief statische informatie. Het is veel zinniger om de waarden pas weg te schrijven zodra het programma afgelopen is.

Wat ik aan probeer te geven: een goede allesomvattende structuur is lang niet zo simpel als je in je startpost doet vermoeden. Er komt heel wat meer bij kijken dan alleen simpele .ini-bestandjes, als je het echt goed wilt maken.

De basis is simpel, de uitwerking kun je zo gecompliceerd maken als je wil, zolang je het maar volgens de (overigens hele simpele) specificatie doet.

En dan is er nog de vraag of .ini-bestanden wel zo'n goede basis zijn. Ik zou zeggen van niet.

INI's zijn in principe hele simpele bestanden, maar je kunt er met een beetje slimmigheid heel veel info in kwijt. Hoe simpeler de basis is, hoe beter. Heeft je toepassing meer nodig, dan kun je (evt. met behulp van dingen zoals services en libraries) het er zelf bijbouwen terwijl de basisstructuur hetzelfde is.

Zelfde voor het concept van ConfigurationIDs. Een bestand in de homedirectory van de user zetten voor een user-specifieke versie is gewoon veel eenvoudiger en net zo effectief.

Je kunt die bestanden prima in de homedir zetten. En een profiel is geen user. Er zijn talrijke applicaties die er meerdere profielen op na houden, bijvoorbeeld verschillende instellingen voor specifieke taken.

Je huidige opzet lijkt me te bewerkelijk om praktisch te zijn, zonder echt duidelijke voordelen.

Het hoeft niet bewerkelijk te zijn als je dat niet wilt.

Nogmaals aan iedereen: IniDB is de universele basis, niet het einde

BTW: De eerste versie van de specifiecatie verschijnt binnenkort.

[ Voor 3% gewijzigd door Verwijderd op 12-04-2005 17:19 . Reden: Additie ]

[Verwijderd]

ja sorry ik zie er weinig heil in. het is nog niet goed doordacht om de vele wensen van configuraties te kunnen ondersteunen. En de vragen van andere Got-ers doe je me even te makkelijk van de hand met rare workarounds. Ik ga het iig niet gebruiken.

[Creepy]

dus je hebt iets verzonnen, het voldoet niet voor een aantal mensen, en dan moeten ze het zelf maar gaan uitbreiden? Right

Naar mijn idee ga je nu ini bestanden everywhere the place krijgen. Er staat niks meer centraal en je zult in het "centrale" bestand eens moeten gaan zoeken waar wat staat en dan maar hopen dat je geen prog's hebt geinstalleerd die de boel hebben uitgebreidt.

Vertel me nu eens 1 ding: wat is nu echt het voordeel van het windows register waar alles centraal staat en wat lang niet zo log is als jij doet voorkomen?

De meeste settings kunnen in de meeste programma's zelf aangepast worden. Hiervoor hoeft de normale gebruiker niet in de registry of ini bestanden te gaan rommelen. Op het moment dat zoiets nodig is, is dat een fout in het programma, niet in de registry

[ Voor 20% gewijzigd door Creepy op 12-04-2005 17:39 ]

[MisterData]

Wat ik zelf wel een mooi systeem zou vinden is het volgende: een applicatie heeft in een bepaalde map (we noemen het even /settings/mijnapplicatie) een of meerdere .xml bestanden staan waarin properties met values staan. In de userdir *kunnen* dezelfde .xml-bestanden voorkomen (/home/gebruiker/settings/mijnapplicatie/). Op het moment dat de settings geladen worden (dat kan als de applicatie erom vraagt, of als de gebruiker inlogt ofzo...) dan worden de gebruiker-settings als het ware over de applicatie-settings heengelegd. Het resultaat hiervan wordt in een cache-bestand, database of het geheugen opgeslagen door het systeem en kan door de applicatie dan door XPath ofzo worden opgehaald. Het systeem moet ook in staat zijn te onthouden waar een setting vandaan kwam: als ik in een usersettings-bestand heb gezegd dat de achtergrondkleur roze is, en in de default-settings staat blauw, en de app wil (via een preferences-scherm bijvoorbeeld) dat

Voordelen:
• Je kunt niet alleen de user-settings over de 'basis'-settings kunt heenleggen, maar bijvoorbeeld ook een map kunt maken met settings voor een groep users bijvoorbeeld (een beetje wat je nu met een NT-domein ook kunt met policies per OU).
• Je maakt gebruik van de ACL's in je filesystem
• Aanpassen van settings is gemakkelijk: XML is een *heel* gemakkelijk te parsen formaat, biedt goede ondersteuning voor bijvoorbeeld diverse encodings
• Het OS mag zelf beslissen wanneer het de bestanden laadt
• Al je settings op een centrale plaats: /Settings/ApplicatieNaam/*.xml voor de 'globale' of 'basis-settings', /home/Gebruiker/Settings/ApplicatieNaam/*.xml voor de gebruiker-specifieke settings. Profiel migreren is een eitje dan: gewoon de Settings-map kopieren

Nadelen:
• Het laden van de bestanden is en blijft trager dan een binair bestand, geoptimaliseerd voor het opslaan van registerdata. Aan de andere kant hoef je niet het hele zootje altijd in je geheugen geladen te hebben natuurlijk.

• Je moet op de een of andere manier een soort 'listener' op alle settings-files hebben, zodat het systeem weet wanneer het de interne 'database' (het resultaat van het mergen van de settings) kan updaten.

Eventueel zou je in de .xml een soort priority-attribuut kunnen opgeven, zodat je bijvoorbeeld een setting in de applicatie-xml altijd voorrang geeft (en daar kun je dan niet meer overheen met je userxml omdat je de applicatie-xml niet kunt aanpassen als dat is geblokkeerd in de ACL)

Is het wat?

[ Voor 4% gewijzigd door MisterData op 12-04-2005 17:51 ]

[FendtVario]

Ik heb echt mij twijfels of dit werkt. Zoals je aangeeft komen veel gebruikte INI's in een aparte lijst, wie zorgt hiervoor. De code die jouw IniDB moet 'managen' (caching, bijhouden van de veel gebruikte ini's etc) meer regels heeft dan die nodig zijn voor het lezen en schrijven van waarden. Je hebt niet aangegeven in welke taal je het geheel hebt geimplementeerd maar ik ga er derhalve van uit dat je hiervoor de standaard library van Windows gebruikt of een Ini-component gebruikt dat bij je omgeving zit (in Delphi zou dat TIniFile zijn).

Heb je wel eens getest wat sneller is, de registry of IniDB? Ik wel eens ergens gelezen dat als je het start menu opent er 400x een waarde uit de registry wordt gehaald. Dat is echt miliseconden werk want het startmenu openen kost hier niet zo veel tijd.

[Verwijderd]

Creepy schreef op dinsdag 12 april 2005 @ 17:38:
dus je hebt iets verzonnen, het voldoet niet voor een aantal mensen, en dan moeten ze het zelf maar gaan uitbreiden? Right

Nee. Ik ben persoonlijk bereid een heleboel modules ervoor te schrijven die anderen vrij zijn te gebruiken. Ik zeg niet dat ik alleen de specificatie ontwerp, ik zeg alleen dat ik de specificatie simpel wil houden. Dat betekent nog niet dat ik er zelf geen lagen opbouw. Maar dat is een hoger niveau.

Naar mijn idee ga je nu ini bestanden everywhere the place krijgen. Er staat niks meer centraal en je zult in het "centrale" bestand eens moeten gaan zoeken waar wat staat en dan maar hopen dat je geen prog's hebt geinstalleerd die de boel hebben uitgebreidt.

Het gaat niet alleen om instellingen, maar om complete databases en files. Ik gebruik de term ``instelling'' alleen maar omdat het technisch gezien een instelling is. Het kan veel meer bevatten.

Vertel me nu eens 1 ding: wat is nu echt het voordeel van het windows register waar alles centraal staat en wat lang niet zo log is als jij doet voorkomen?

Dit is makkelijk te editen, je kunt een goede klassenstructuur maken, het is uitbreidbaar en simpel om te implementeren.

De meeste settings kunnen in de meeste programma's zelf aangepast worden. Hiervoor hoeft de normale gebruiker niet in de registry of ini bestanden te gaan rommelen. Op het moment dat zoiets nodig is, is dat een fout in het programma, niet in de registry

Daar heb je gelijk in, maar het gaat niet alleen om configuratie, ook om andere opslag.

Ideen (databases, filesystems, uitbreidingen, etc.) die jullie hebben waardeer ik zeer! Deze wil ik namelijk ook in de modules die ik ga schrijven opnemen.

[ Voor 8% gewijzigd door Verwijderd op 12-04-2005 19:09 . Reden: Typo ]

[Verwijderd]

De register zou alleen gebruikt mogen worden om vindplaatsen in op te slaan of OS settings. Alle data meuk van een programma zou in een eigen systeem opgeslagen moeten worden, ini of wat voor formaat dan ook. Niemand gaat toch een grote database in het register proppen, dus waarom wel knopje "a" heeft de user uitgezet en knopje "b" staat aan.

Daarnaast vind ik dat het OS verantwoordelijk moet zijn voor een centrale bak met gegevens en niet een één of ander crappy programma van een particulier. Één systeem waardoor alle progs kunnen communiceren met het OS of contact punten leggen waar andere programma's een brug naar toe kunnen leggen.

[Onno]

Verwijderd schreef op dinsdag 12 april 2005 @ 17:15:
Dat ID kan gewoon in de value ConfigurationID staan.

Dat is niet wat je in eerste instantie beschreef. En als je systeem niet meer weet welk ID de globale configuratie is doordat je dat zelf kunt instellen, hoe vindt ie die globale configuratie dan?

(en waar vindt ie uberhaupt het pad naar de configuratie met ConfigurationID x? dat zie ik eigenlijk nergens staan)

Als je 1 instelling door meerdere onderdelen van progjes wilt laten veranderen, zorg je er toch voor dat je goede sync tussen de 2 hebt? Het is onzinnig om dezelfde waarde door 2 apart ontwikkelde programma's constant te laten veranderen.

Neu. Ik kan zo twee mutts tegelijk starten. Of twee konquerors. Of twee irssi's. En dan gebruiken ze dus allebei dezelfde set settings. En dan kan het dus voorkomen dat ze tegelijk willen gaan knoeien aan die settings. Is het waarschijnlijk? Vast niet. Maar je moet er wel rekening mee houden dat het kan voorkomen.

Het is veel zinniger om de waarden pas weg te schrijven zodra het programma afgelopen is.

Ik heb nergens zo'n grote hekel aan als programma's die dat doen. Dan heb je wat settings veranderd, en een paar weken later crasht het programma of je pc.. weg settings.

De basis is simpel, de uitwerking kun je zo gecompliceerd maken als je wil, zolang je het maar volgens de (overigens hele simpele) specificatie doet.

En ik denk dat de basis te simpel (of onhandig in ieder geval) is, waardoor het inderdaad al snel gecompliceerd wordt. Met bijvoorbeeld XML heb je gewoon al heel veel wat je wilt kunnen beschikbaar, en hoef je geen extra logica te schrijven om wat complexere dingen te kunnen doen.

Hoe simpeler de basis is, hoe beter.

Nee!

Natuurlijk wil je geen topzware basislaag hebben, maar je kunt echt wel te simpel bezig zijn, waardoor het juist weer complex wordt. Om een voorbeeld te noemen: FAT zal nooit een echt goed bestandssysteem worden, al gooi je er nog zoveel laagjes bovenop. Lange bestandsnamen in FAT zijn bijvoorbeeld een enorm ranzige en bewerkelijke hack, die alleen maar nodig was omdat de basis verkeerd was. Had je namespaces gehad, dan was er geen probleem geweest. Ook al had je niet vanaf het begin een lange-bestandsnamen-namespace. Datzelfde geldt naar mijn mening voor jouw opzet. Je kunt er wel dingen bovenop gooien, maar het blijven altijd lelijke hacks. Zorg voor een goede basis, en het wordt al een stuk aantrekkelijker.

Verwijderd schreef op dinsdag 12 april 2005 @ 19:03:
Het gaat niet alleen om instellingen, maar om complete databases en files. Ik gebruik de term ``instelling'' alleen maar omdat het technisch gezien een instelling is. Het kan veel meer bevatten.

Zoals? Bij een database denk ik heel erg aan een multi-client-safe systeem, maar net beweerde je nog dat het daar nadrukkelijk niet voor bedoeld was.

[ Voor 10% gewijzigd door Onno op 13-04-2005 16:02 ]

[Creepy]

Je wilt daadwerkelijk DB of zelfs filesysteem achtige zaken gaan bouwen puur en alleen op inifiles? Ik begin het idee te krijgen dat je niet precies beseft waar je nu mee bezig bent... voor een paar settings opslaan voldoet een ini file prima. Maar een soort van FS in files die al op een ander FS staan.... en dan wil ik het niet eens hebben over de mogelijkheden om snel dingen op te zoeken in flinke hoeveelheden data.........

[Verwijderd]

Verwijderd schreef op dinsdag 12 april 2005 @ 22:27:
De register zou alleen gebruikt mogen worden om vindplaatsen in op te slaan of OS settings. Alle data meuk van een programma zou in een eigen systeem opgeslagen moeten worden, ini of wat voor formaat dan ook. Niemand gaat toch een grote database in het register proppen, dus waarom wel knopje "a" heeft de user uitgezet en knopje "b" staat aan.

Daarnaast vind ik dat het OS verantwoordelijk moet zijn voor een centrale bak met gegevens en niet een één of ander crappy programma van een particulier. Één systeem waardoor alle progs kunnen communiceren met het OS of contact punten leggen waar andere programma's een brug naar toe kunnen leggen.

De data hoeft niet ingeladen te worden als dat niet nodig is. Als je gewoon de root INI van de datafiles in de applicatie-specifieke INI file vermeld, dan hoeft er geen enkel programma aan te zittten, de applicatie weet dan wel waar de data staat. Daarom kun je het wel gebruiken om data in te bewaren.

Ideaal is het OS ook verantwoordelijk voor het bijhouden van gegevens, en dat doen ze wel elk op een eigen manier. Alleen in de praktijk is een portable systeem met een portable API toch handiger.

Over het ``een of ander crappy programma van een particulier'': Linux was eerst ook een crappy programma van een particulier. Nu is het een van de belangrijkste besturingssystemen. Als ideen van een particulier komen is dat niet per definitie slecht. Het gaat om de uitwerking ervan. En ik ben bepaald niet van plan mijn implementatie crappy te maken. Zo heb je crappy XML-editors en goede XML-editors. Het is beide gebaseerd op dezelfde standaard, alleen de implementatie is anders.

[ Voor 31% gewijzigd door Verwijderd op 13-04-2005 01:06 . Reden: Edit0: Additie Edit1: Typo ]

[Verwijderd]

Onno schreef op dinsdag 12 april 2005 @ 22:48:
[...]

Dat is niet wat je in eerste instantie beschreef. En als je systeem niet meer weet welk ID de globale configuratie is doordat je dat zelf kunt instellen, hoe vindt ie die globale configuratie dan?

(en waar vindt ie uberhaupt het pad naar de configuratie met ConfigurationID x? dat zie ik eigenlijk nergens staan)

Die staat in het voorbeeld nog gewoon in general, het wordt niet vast onderdeel van de standaard.

[...]

Neu. Ik kan zo twee mutts tegelijk starten. Of twee konquerors. Of twee irssi's. En dan gebruiken ze dus allebei dezelfde set settings. En dan kan het dus voorkomen dat ze tegelijk willen gaan knoeien aan die settings. Is het waarschijnlijk? Vast niet. Maar je moet er wel rekening mee houden dat het kan voorkomen.

De laatste die de opdracht gaf om de settings te saven is de winnaar

[...]

Ik heb nergens zo'n grote hekel aan als programma's die dat doen. Dan heb je wat settings verandert, en een paar weken later crasht het programma of je pc.. weg settings.

Je hebt een punt. Dat kan ik dus beter niet doen.

[...]

En ik denk dat de basis te simpel (of onhandig in ieder geval) is, waardoor het inderdaad al snel gecompliceerd wordt. Met bijvoorbeeld XML heb je gewoon al heel veel wat je wilt kunnen beschikbaar, en hoef je geen extra logica te schrijven om wat complexere dingen te kunnen doen.

Hoeft ook niet in INI's. Voorbeeld:

code:

[Object:Foo]
Foo:FirstComponent:Online=1
Foo:SecondComponent:Online=0
Foo:Connections:Bar:Connected=0

[...]

Nee!

Natuurlijk wil je geen topzware basislaag hebben, maar je kunt echt wel te simpel bezig zijn, waardoor het juist weer complex wordt. Om een voorbeeld te noemen: FAT zal nooit een echt goed bestandssysteem worden, al gooi je er nog zoveel laagjes bovenop. Lange bestandsnamen in FAT zijn bijvoorbeeld een enorm ranzige en bewerkelijke hack, die alleen maar nodig was omdat de basis verkeerd was. Had je namespaces gehad, dan was er geen probleem geweest. Ook al had je niet vanaf het begin een lange-bestandsnamen-namespace. Datzelfde geldt naar mijn mening voor jouw opzet. Je kunt er wel dingen bovenop gooien, maar het blijven altijd lelijke hacks. Zorg voor een goede basis, en het wordt al een stuk aantrekkelijker.

Lelijke hacks? Om bij jouw bestandsnamenvoorbeeld te blijven, maken we van:

code:

[File:653434]
FileName(Max8.3)=DITISVEE.LST

gewoon:

code:

[File:653434]
FileName(Max8.3)=DITISVEE.LTE
ExtendedFileName(Max255)=Dit Is Veel Te Lang

Simpel zat.

INI's zijn bovendien flexibel. Je hebt geen velden van vaste grootte ofzow, behalve als je dat in de structuur zelf implementeert. Komt de ene app een onbekend veld tegen, negeert die het gewoon.

[...]

Zoals? Bij een database denk ik heel erg aan een multi-client-safe systeem, maar net beweerde je nog dat het daar nadrukkelijk niet voor bedoeld was.

Ik zei _relatief_ statische data. Zodra de data (semi-) permanent weggeschreven moet worden zet je een lock op het juiste punt (file, section, line, etc.), schrijf je het weg, heft de lock op, klaar. Als je IPC gaat implementeren, kun je dat beter memory-based of network-based doen. Als je 2 instances van mutt of konqueror open hebt, rijden ze elkaar ook in de wielen als je eerst in de ene mutt de mailbox leest, dat dan bewerkt, en voor je het in de 1e instance opslaat de informatie in de 2e instance mutt bewerkt en ook opslaat. Als oplossing kun je bovendien ook een soort revisiesysteem implementeren, zoals:

1. Prog 1 leest een record met een revisienummer van 5226.
2. Prog 2 doet hetzelfde.
3. Prog 1 is klaar, stuurt een verzoek tot schrijven naar de database.
4. De database vergelijkt het revisienummer met die in de database, keurt het goed, en schrijft de data
weg met revisienummer 5227.
5. Prog 2 is ook klaar, en stuurt ook een verzoek naar de database.
6. De database ziet dat het revisienummer niet klopt met dat in de database, dus geeft de melding
terug aan Prog 2 dat zijn gegevens verouderd zijn.

Nu kan Prog 2 twee dingen besluiten: 1. Zijn werk opnieuw doen; en 2. Het gewoon wegschrijven met alle gevolgen van dien.

Als Prog 2 zijn werk besluit opnieuw te doen, vraagt hij een editlock aan op het record. Hij leest het
record opnieuw, voert zijn werk uit, en schrijft het nieuwe record weg. Het heft de editlock op, waarna
Prog 1 zijn gang weer kan gaan.

[ Voor 13% gewijzigd door Verwijderd op 13-04-2005 01:20 . Reden: Additie ]

[Verwijderd]

Creepy schreef op dinsdag 12 april 2005 @ 23:14:
Je wilt daadwerkelijk DB of zelfs filesysteem achtige zaken gaan bouwen puur en alleen op inifiles? Ik begin het idee te krijgen dat je niet precies beseft waar je nu mee bezig bent... voor een paar settings opslaan voldoet een ini file prima. Maar een soort van FS in files die al op een ander FS staan.... en dan wil ik het niet eens hebben over de mogelijkheden om snel dingen op te zoeken in flinke hoeveelheden data.........

Ik weet precies waar ik mee bezig ben. Een file/block device maken met direct na de header de root INI. Die begint met informatie over zichzelf: welke byteranges neemt het in beslag, wat is de naam van de INI in de virtuele directorystructuur, etc. Vervolgens verwijzingen naar de root klassen (lees: virtuele directories) Dan de record reference table (record ID, byteranges waar het in staat, lockstate, etc). Dan de data in INI-formaat. Je kunt het zelfs mounten in raw mode (zoiets als ``-t dbfsraw'' ipv ``-t dbfs''), zodat je de virtuele directorystructuur kunt benaderen met alle record INI's in de respectievelijke directories. In elke directory vindt je dan ook een dir ``dirinfo/' met alle INI's van de subdirs. Er staat in de root dir ook een dir ``raw/'' met de dir's ``all/'', ``files/'', en ``dirs/'', met respectievelijk alle INI's, alle directory INI's, en alle file INI's. Eigenlijk een soort makkelijke toegang tot het onderliggende van het FS. Bovendien kan 1 file/dir INI op meerdere plaatsen in de directorystructuur gemount worden. Gewoon het recordnummer in de filelist van de juiste dir INI plaatsen met de gewenste naam.

[Creepy]

Je gaat dus nu je eigen FS layer schrijven om je eigen ini's in op te slaan? Het zal wel aan mij liggen maar het voordeel daaraan ontgaat me volledig (net als het voordeel t.o.v. bijv. de windows registry of /etc/ in Linux).
Je DB functionaliteit kun je nu al beter vergeten denk ik want "de laatste die de settings wegschrijft is de winnaar" is dus niet wat je wilt hebben (lost update problemen zijn niet zo heel fijn).

Je vertelt het leuk en je maakt er een mooi verhaal van maar kan je me eens kort en bondig en onderbouwd vertellen wat de voordelen aan jou systeem zijn? Want ik mis dat volledig

[riezebosch]

Al is gekeken naar IsolatedStorage in .NET? Dan kan je per gebruiker in een op een centrale plaats bewaard bestand dingen opslaan. Argument daarvoor is ook dat de Registry nogal is vervuild raakt. Voordeel hiervan is dat je gewoon me XML je eigen format kan hanteren.

[Verwijderd]

Creepy schreef op woensdag 13 april 2005 @ 09:12:
Je gaat dus nu je eigen FS layer schrijven om je eigen ini's in op te slaan?

Nee. Interne INI's in DBFS kunnen alle data en velden bevatten die nodig zijn, dus je kunt er alle soorten files op opslaan.

Het zal wel aan mij liggen maar het voordeel daaraan ontgaat me volledig (net als het voordeel t.o.v. bijv. de windows registry of /etc/ in Linux).

Idd. Maar IniDB is een basis voor zeer eenvoudige en toch krachtige en flexibele gegevensopslag. Dat kan alles zijn wat je maar wilt.

Je DB functionaliteit kun je nu al beter vergeten denk ik want "de laatste die de settings wegschrijft is de winnaar" is dus niet wat je wilt hebben (lost update problemen zijn niet zo heel fijn).

Idd. Het ``de laatste settings die hij wegschrijft is de winnaar'' ga ik alleen in de eerdere developmentfasen gebruiken. De revisienummers en/of de editlock zijn handiger mechanismen.

Je vertelt het leuk en je maakt er een mooi verhaal van maar kan je me eens kort en bondig en onderbouwd vertellen wat de voordelen aan jou systeem zijn? Want ik mis dat volledig

1. Het is heel lightweight.
2. Je kunt er alles mee.
3. Makkelijk uitbreidbaar.
4. Cross-platform (het kan zelfs draaien onder een Commandore 64 als het nodig is).
5. Ruimte voor eigen implementaties, al zal ik er ook een aantal schrijven die volledig functioneel zijn.
6. Mogelijkheid voor embedding (alle soorten binaire files en textfiles).
7. Makkelijk om er lagen op te bouwen die de functionaliteit uitbreiden zonder geharrewar (of rare hacks).

[ Voor 2% gewijzigd door Verwijderd op 13-04-2005 12:46 . Reden: Typo ]

[Verwijderd]

Het feit dat kan, wil nog niet zeggen dat je keuzes correct zijn. Je gebruikt een attribuut gericht systeem. dat neem je niet als basis voor een configuratie systeem. Daarmee is eigelijk alles al gezegd.

[Verwijderd]

Verwijderd schreef op woensdag 13 april 2005 @ 13:34:
Het feit dat kan, wil nog niet zeggen dat je keuzes correct zijn. Je gebruikt een attribuut gericht systeem. dat neem je niet als basis voor een configuratie systeem. Daarmee is eigelijk alles al gezegd.

Ik heb al gezegd: het is niet meer alleen voor simpele instellingen. Je kunt er van alles mee doen. Er komen meerdere specificaties, b.v. voor DBFS, die allemaal van de standaard IniDB specificatie afhangen. Je kunt er alles mee doen. Aangezien ik een aantal volledige functionele en nuttige implementaties en toepassingen ga schrijven hoeft een ander het wiel niet uit te vinden

[Verwijderd]

Verwijderd schreef op woensdag 13 april 2005 @ 14:26:
Ik heb al gezegd: het is niet meer alleen voor simpele instellingen. Je kunt er van alles mee doen. Er komen meerdere specificaties, b.v. voor DBFS, die allemaal van de standaard IniDB specificatie afhangen. Je kunt er alles mee doen. Aangezien ik een aantal volledige functionele en nuttige implementaties en toepassingen ga schrijven hoeft een ander het wiel niet uit te vinden

Nee jij begrijpt het domweg nog steeds niet.
- Een ini file heeft de beperking enkel attributen op te slaan.
- Een ini file kent geen regels omtrent het verplicht stellen van die attributen

Elke laag die jij er op wilt bouwen is niets anders dan een smerige hack om de tekortkommingen van het onderliggende systeem te overkomen (iemand maakte al de vergelijking met fat32). Bottomline is dus domweg dat je een verkeerd initieel formaat hebt.

Als we dan bijvoobeeld kijken naar XML kun je direct geneste attributen vastleggen maar ook domweg properties opnemen zoals je dat gewend in een ini file. Verder is doormiddel van een scheme of dtd het afdwingen van de minimale configuratie wel mogelijk.

Dus je begint domweg verkeerd.

[Creepy]

Verwijderd schreef op woensdag 13 april 2005 @ 12:45:
1. Het is heel lightweight.
2. Je kunt er alles mee.
3. Makkelijk uitbreidbaar.
4. Cross-platform (het kan zelfs draaien onder een Commandore 64 als het nodig is).
5. Ruimte voor eigen implementaties, al zal ik er ook een aantal schrijven die volledig functioneel zijn.
6. Mogelijkheid voor embedding (alle soorten binaire files en textfiles).
7. Makkelijk om er lagen op te bouwen die de functionaliteit uitbreiden zonder geharrewar (of rare hacks).

1: Vind je? Ini files everwhere the place of in een eigen FS layer.. daar komt dus een API laag omheen die minstens zo "log" is als dat van de Windows registry
2: Ik kan er niet alles in op slaan. Binaire formaten moeten erin "gehackt" worden omdat ini files per definitie tekst zijn. BASE64 en andere zut blijf ik hacks (en bloat!) vinden
3: Voor wat? Voor DB functionaliteit heb ik een DB. Voor filesystem achtige zaken heb ik een filesysteem, voor etc. etc. Je bent naar mijn idee TE algemeen bezig.
4: Dat is de /etc/ oplossing van Unix/linux ook
5: Eigen interpretaties dus, die niet compatible met elkaar zijn. En dat vindt je dus een voordeel?
6: zie punt 2
7: zie punt 2, Ik blijf het hacks vinden.

Inifiles zijn leuk om wat tekstuele dingen in op te slaan, en makkelijk aan te passen met een tekst editor (wat eigenlijk niet eens nodig zou hoeven zijn als de applicaties je de settings laten instellen). En bovenop tekstfiles wil je vanalles en nog wat gaan bouwen? Er is een reden waarom database hun eigen fileformaat of eigen FS formaat hebben. En er is ook een reden waarom wat geavanceerdere filesystemen een redelijk lange ontwikkeltijd hebben waar meerdere mensen over hebben nagedacht en aan gebouwd. En om 1 of andere reden hebben geen van alle een tekstbestand als basis

[Onno]

Verwijderd schreef op woensdag 13 april 2005 @ 01:02:
Lelijke hacks? Om bij jouw bestandsnamenvoorbeeld te blijven, maken we van:

code:

[File:653434]
FileName(Max8.3)=DITISVEE.LST

gewoon:

code:

[File:653434]
FileName(Max8.3)=DITISVEE.LTE
ExtendedFileName(Max255)=Dit Is Veel Te Lang

Een voorbeeldbeperking van FAT is niet direct representatief voor de beperkingen van jouw systeem. Dit voorbeeld slaat nergens op, omdat de lengte van een waarde in eerste instantie al geen beperking was in .ini bestanden. Wat bijvoorbeeld wel een beperking is dat je niet alle tekens als naam of waarde kunt gebruiken. Wat als ik "bla=bla" als naam van een waarde wil hebben? Dat kan niet. Wat als ik een newline in een waarde wil hebben? Ook niet. En dan kom je in de afdeling lelijke hacks, zoals je demonstreerde met je manier om XML fragmenten op te slaan.

Het feit dat iedereen het een onzalig idee vindt moet toch genoeg zijn om misschien eens naar een iets ander ontwerp te kijken. (waarom begin je zo'n thread anders, als je toch al bij voorbaat van de perfectie van je systeem overtuigd bent?) Op zich is een algemeen configuratiesysteem namelijk helemaal niet verkeerd.

[ Voor 16% gewijzigd door Onno op 13-04-2005 16:12 ]

[Verwijderd]

Verwijderd schreef op woensdag 13 april 2005 @ 14:57:
[...]
Nee jij begrijpt het domweg nog steeds niet.
- Een ini file heeft de beperking enkel attributen op te slaan.

Nee, je kunt er complete datastrings in opslaan als je dat wilt. Zoals:

code:

[File:Contents]
NumLines=3
Line0=%&#$^&%^^$G%425^&%@W$
Line1=FSH$^W%ATGFV^$W^t34dG$
Line2=AG#%TQH$^qh46qh$^yhAE46
Line3=afye5aYH$%aG%$Y%$$TAT$

Nu heb ik maar wat getrommeld op het toetsenbord, maar dat moeten binaire strings voorstellen

Er zijn maar 5 ASCII tekens die echt problemen opleveren in een INI-file:

code:

009(TAB)
010(LF)
013(CR)
026(EOF)

Als je nou gewoon voor 009 het woord ``tab'' gebruikt, voor 010 ``lf'', voor 013 ``cr'' en voor 026 ``eof'' ipv de respectievelijke tekens, heb je daar geen last meer van. Komen die strings toevallig al voor in het bestand, dan wordt het ``tabtab'', ``lflf'', etc.

- Een ini file kent geen regels omtrent het verplicht stellen van die attributen

Dat ga ik juist vastleggen in de IniDB standaard die de standaardelementen van de INI files definieert. De DBFS standaard specificeerd de methode om er een filesystem van te maken, maar de regels van IniDB gelden ook nog steeds.

Elke laag die jij er op wilt bouwen is niets anders dan een smerige hack om de tekortkommingen van het onderliggende systeem te overkomen (iemand maakte al de vergelijking met fat32). Bottomline is dus domweg dat je een verkeerd initieel formaat hebt.

Heb ik niet. Het initieel formaat defineert alleen de basis. Zoals de manier waarop de header van alle typen filesystems of de partitietabel van alle harde schijven in elkaar zit.

Als we dan bijvoobeeld kijken naar XML kun je direct geneste attributen vastleggen maar ook domweg properties opnemen zoals je dat gewend in een ini file. Verder is doormiddel van een scheme of dtd het afdwingen van de minimale configuratie wel mogelijk.

Dus je begint domweg verkeerd.

XML neemt veel meer ruimte in. Voor dingen als DBFS of andere datbases is dat een belangrijk punt. Bovendien zijn geneste attributen prima mogelijk in INI-bestanden, zelfs zonder embedding:

[code]
[Entry_Foo]
DefineAttribute:Blaat
DefineAttribute:Blaat:Value
Attribute:Blaat:Value="Bar"
EndAttribute:Blaat

[ Voor 15% gewijzigd door Verwijderd op 13-04-2005 17:22 . Reden: Te vroeg op enter gedrukt 8)7 ]

[Onno]

Verwijderd schreef op woensdag 13 april 2005 @ 17:16:
Als je nou gewoon voor 009 het woord ``tab'' gebruikt, voor 010 ``lf'', voor 013 ``cr'' en voor 026 ``eof'' ipv de respectievelijke tekens, heb je daar geen last meer van. Komen die strings toevallig al voor in het bestand, dan wordt het ``tabtab'', ``lflf'', etc.

Dit zegt wel genoeg over hoeveel je al met verschillende data-coderingen gewerkt hebt.

Hint: hoe codeer je twee \009\009 als tabtab al voor "tab" staat?

[Gé Brander]

Niet om te flamen, maar gezien je andere topic die binnen no time op slot ging, begin je je naam eer aan te doen...

Het lijkt er op dat je kritiek vraagt maar niet accepteert.

Alles wat als hint gegeven wordt dat niet echt slim is of niet aan te raden is, daar kom je met een opmerking die de kritiek teniet doet... Het enige waar je op uit bent is bevestiging dat je goed bezig ben en een super oplossing bedacht hebt. Helaas gaat het daar juist mank.

[Verwijderd]

Creepy schreef op woensdag 13 april 2005 @ 15:54:
[...]

1: Vind je? IINI files everwhere the place of in een eigen FS layer.. daar komt dus een API laag omheen die minstens zo "log" is als dat van de Windows registry

INI files zijn nu al everywhere in the place. Bovendien is het nu, dankzij jullie kritiek, een algemene holder voor data.

2: Ik kan er niet alles in op slaan. Binaire formaten moeten erin "gehackt" worden omdat ini files per definitie tekst zijn. BASE64 en andere zut blijf ik hacks (en bloat!) vinden

BASE64? Hacks? Wat let je om INI files binair te openen (nadat het andere erin is gezet) en op de juiste plaats het in te voegen?

3: Voor wat? Voor DB functionaliteit heb ik een DB. Voor filesystem achtige zaken heb ik een filesysteem, voor etc. etc. Je bent naar mijn idee TE algemeen bezig.

Ik ga een hele zooi verschillende toepassingen ontwerpen. Ik heb nu al 1001 ideen. Zal ik die posten? Dan ga ik prompt over de 64K heen DBFS is een FileSystem, en werkt als een FileSystem, alleen de interne structuur is als een database, net als in WinFS. Ook kun je DBFS prima gebruiken om bijvoorbeeld een muziekcollectie te ordenen in een logische directorystructuur. In de Directory/File INI's (met dbfsraw of een tooltje dat ik moet devven), kun je een sectie opnemen zoals ``DBInfo'':

code:

<header volgens de IniDB-standaard>
<filesystem-specifieke informatie>

[DBInfo]
Artiest=<artiest>
NummerOpCd=<nummeropcd>
Album=<album>
<zoveel zooi als je wilt>

[PhysicalData]
<de file zelf>

Daar ga ik ook wat voor devven zodat het een point-en-click oplossing wordt, of zo je wilt, een database editor.

4: Dat is de /etc/ oplossing van Unix/linux ook

Jep, maar die werken niet met een standaard die volgens vaste specificaties werkt en toch zo uitbreidbaar is

5: Eigen interpretaties dus, die niet compatible met elkaar zijn. En dat vindt je dus een voordeel?

[b]Implementaties[b] zei ik, geen interpretaties. Daar is een verschil tussen. De basisstructuur van de INI wordt gedefineerd. Zolang het daaraan voldoet, mag een app zijn data op elke manier wegschrijven die de programmeur wil. Je hebt HTML 4 Strict, en alle browsers moeten eraan voldoen. Al doen ze dat bij HTML niet, bij zoiets eenvoudigs als IniDB verwacht ik wel dat ze zich aan de (zeer losse) standaard houden.

6: zie punt 2
7: zie punt 2, Ik blijf het hacks vinden.

$me heeft nog eens nagedacht en een veel betere oplossing voor het includen van files. Het is simpel: als je er een binaire datastroom erin wilt opslaan, zet je na alle IniDB-compatibele data gewoon:

code:

[IniDB.InterruptParsing]
LineToResumeParsing=<linenumber of 0 om te eindigen>

<data>

neer. Dat is natuurlijk niet bedoeld voor instellingen ofzow (daar is immers IniDB voor), maar voor overige belangrijke data (denk aan de fileinhoud bij DBFS) die om een of andere reden ongewijzigd op moeten worden geslagen.

Inifiles zijn leuk om wat tekstuele dingen in op te slaan, en makkelijk aan te passen met een tekst editor (wat eigenlijk niet eens nodig zou hoeven zijn als de applicaties je de settings laten instellen). En bovenop tekstfiles wil je vanalles en nog wat gaan bouwen? Er is een reden waarom database hun eigen fileformaat of eigen FS formaat hebben. En er is ook een reden waarom wat geavanceerdere filesystemen een redelijk lange ontwikkeltijd hebben waar meerdere mensen over hebben nagedacht en aan gebouwd. En om 1 of andere reden hebben geen van alle een tekstbestand als basis

[/quote]

Tja, ik denk daar dus anders over. INI-bestanden zijn geen probleem om uit te breiden met meer attributen. Je hoeft er geen extra ruimte ervoor te reserveren.

De meest uitgebreide versie van de structuur van IniDB is simpel:

code:

; IniDB Example File

[General]
FileRevision=0
IniDBRevision=1

[INIClasses]
System=system/ini.ini
Applications=applications/ini.ini

[Class:SubClass]
Class:SubClass:Setting0=1
Class:SubClass:Attribute55:Value=bar

[IniDB.InterruptParsing]
LineToResumeParsing=22

BAGATGSRHRHREHBG%#QEYGHB&U5tjk46hbnwyhbst
uyetJN^$tjafu5herjnh35qj46qh6
%uhbu5lk75jk767565657ku57kw57k7kw576ke8k64l784l4757jnqy7j53j373733762hbr6s7yjn54e

[Class:SubClass]
Class:SubClass:Setting1=1
Class:SubClass:Attribute54:Value=blaatkoe

Zoals je ziet, is het eenvoudig om nog extra info te appenden in de INI. Zo kun je ook een instelling veranderen in 1 die langer is dan de vorige zonder het bestand op te schuiven. Alle secties met dezelfde naam worden als 1 sectie gezien. Op een gegeven moment wordt dit gefragmenteerd, maar in een zeer korte periode kan dit worden rechtgezet. Een beetje schuiven met de data en het is weer op orde.

[ Voor 5% gewijzigd door Verwijderd op 13-04-2005 19:35 . Reden: Typo (ja, ik typ soms te snel :P) ]

[Verwijderd]

Onno schreef op woensdag 13 april 2005 @ 16:10:
[...]

Een voorbeeldbeperking van FAT is niet direct representatief voor de beperkingen van jouw systeem. Dit voorbeeld slaat nergens op, omdat de lengte van een waarde in eerste instantie al geen beperking was in .ini bestanden. Wat bijvoorbeeld wel een beperking is dat je niet alle tekens als naam of waarde kunt gebruiken. Wat als ik "bla=bla" als naam van een waarde wil hebben? Dat kan niet. Wat als ik een newline in een waarde wil hebben? Ook niet. En dan kom je in de afdeling lelijke hacks, zoals je demonstreerde met je manier om XML fragmenten op te slaan.

Dat kan wel, zolang de bestandsnaam maar geen CRLF bevat, en dat heb zo'n ding nog nooit zien doen

Het feit dat iedereen het een onzalig idee vindt moet toch genoeg zijn om misschien eens naar een iets ander ontwerp te kijken. (waarom begin je zo'n thread anders, als je toch al bij voorbaat van de perfectie van je systeem overtuigd bent?) Op zich is een algemeen configuratiesysteem namelijk helemaal niet verkeerd.

Bij voorbaat ben ik helemaal niet dat mijn eerste idee perfect is. Als je de thread goed volgt neem ik steeds jullie adviezen ter harte en geef ik een oplossing. Jullie geven weer een beperking aan en het begint weer opnieuw. Tot nu toe heb ik nog geen onoplosbare limitaties gevonden Ik zal jullie ook wel noemen in de Credits van de specificatie als adviseurs, aangezien ik jullie erg dankbaar ben voor jullie nuttige commentaar. Dat is debuggen

[Gerco]

code:

LineToResumeParsing=<linenumber of 0 om te eindigen>

Je weet dat binaire data uit meer kan bestaan dan alleen tekst? En dat LineNumbers dus meteen hun betekenis verliezen zodra je daarmee bezig gaat? Je kunt geen regelnummer opgeven waar hij moet verdergaan omdat het bestand niet meer line georienteerd is zodra je binaire data erin gaat dumpen.

Verder kun je wel succesvol een systeem als dit gaan maken en dat kan ook best werken, maar ik beloof je dat het zeker twee maal trager is dan de registry en als je er evenveel data in gaat stoppen wil ik zelfs tot 100 keer gaan. Ik ben benieuwd naar je implementatie, ik zou 'em graag testen (op linux weliswaar, het is immers platform onafhankelijk).

Ik kan nog wel 100k kritiek gaan leveren (ik heb het nog niet over encodings gehad, utf-8, etc), maar ten eerste hebben de anderen dat al voor me gedaan en ten tweede lijkt het me helaas weinig zinvol.

[ Voor 32% gewijzigd door Gerco op 13-04-2005 19:46 ]

[Verwijderd]

c70070540 schreef op woensdag 13 april 2005 @ 19:07:
Niet om te flamen, maar gezien je andere topic die binnen no time op slot ging, begin je je naam eer aan te doen...

Idd, dat doe ik IRL al jaren

Het lijkt er op dat je kritiek vraagt maar niet accepteert.

Helemaal niet. Ik vraag om kritiek (in dit geval: bugs in de specificatie), ik pas mijn ideen aan, plaats ze, en wacht op het volgende probleem.

Alles wat als hint gegeven wordt dat niet echt slim is of niet aan te raden is, daar kom je met een opmerking die de kritiek teniet doet... Het enige waar je op uit bent is bevestiging dat je goed bezig ben en een super oplossing bedacht hebt. Helaas gaat het daar juist mank.

Voor alle duidelijkheid: Ik ben niet dit topic begonnen om uit te roepen: JAAA! IK BEN EEN SUPERPROGRAMMEUR(TM)! WORSHIP AND CONGRATULATE ME. Ik maak een specificatie die voor mij, en hopelijk voor meerdere mensen, prima werkt. Als ik alleen aan mijzelf dacht dan had ik de specificatie gewoon gelaten voor wat het is en dat gebruikt. Ik probeer juist andere mensen te _helpen_ door de specificatie, en mijn implementatie, van bugs te ontdoen. Als alles goed genoeg werkt, dan ga ik serieus nadenken over hoe de boel goed te adverteren in de open-source wereld, zodat andere mensen weten dat het er is en het kunnen gebruiken als ze het goed voor hun programma's vinden. $me schrijft ook zelf een aantal implementaties die meer zijn dan teststukken/voorbeelden, maar volledig functioneel en handig zijn. GPL, dus voor iedereen beschikbaar. En dat dus niet om mezelf bekend te maken, maar om mensen te helpen met een goede manier om data op te slaan.

[Verwijderd]

Gerco schreef op woensdag 13 april 2005 @ 19:43:

code:

LineToResumeParsing=<linenumber of 0 om te eindigen>

Je weet dat binaire data uit meer kan bestaan dan alleen tekst? En dat LineNumbers dus meteen hun betekenis verliezen zodra je daarmee bezig gaat? Je kunt geen regelnummer opgeven waar hij moet verdergaan omdat het bestand niet meer line georienteerd is zodra je binaire data erin gaat dumpen.

Je hebt een punt. Dat wordt dus:

code:

ByteToResumeParsing=<bytenummer of 0 om te eindigen>

Verder kun je wel succesvol een systeem als dit gaan maken en dat kan ook best werken, maar ik beloof je dat het zeker twee maal trager is dan de registry en als je er evenveel data in gaat stoppen wil ik zelfs tot 100 keer gaan. Ik ben benieuwd naar je implementatie, ik zou 'em graag testen (op linux weliswaar, het is immers platform onafhankelijk).

Ik develop het eerst voor Linux, omdat ik me meer op mijn gemak voel om een gewoon programma te schrijven dan een met die vreemde overhead van Windows progjes (no pun intended). Dus als jij dan mij de bugs geeft die je vindt, dan kan ik ze fixen

Ik kan nog wel 100k kritiek gaan leveren (ik heb het nog niet over encodings gehad, utf-8, etc), maar ten eerste hebben de anderen dat al voor me gedaan en ten tweede lijkt het me helaas weinig zinvol.

Geef die kritiek! Dan kan ik de specificatie erop aanpassen, om zo samen tot een nog beter resultaat te komen.

[ Voor 2% gewijzigd door Verwijderd op 13-04-2005 20:02 . Reden: Typo (ik blijf ze maar maken he?) ]

[D4Skunk]

Zeurkous, check this out :
Interchange File format

Dit komt toch wel redelijk dicht bij wat jij wenst te doen dacht ik, en het bestaat al xx jaar

[Verwijderd]

D4Skunk schreef op woensdag 13 april 2005 @ 20:57:
Zeurkous, check this out :
Interchange File format

Dit komt toch wel redelijk dicht bij wat jij wenst te doen dacht ik, en het bestaat al xx jaar

IniDB is plain text, kan binaire data bevatten zo je wilt, is overzichtelijker, is zowel attribute-based als chunk-based, dus veel flexibeler.

[Verwijderd]

Verwijderd schreef op donderdag 14 april 2005 @ 11:18:
IniDB is plain text, kan binaire data bevatten zo je wilt, is overzichtelijker, is zowel attribute-based als chunk-based, dus veel flexibeler.

De bzwaren zijn gemaakt, je hebt ze weerlegt met smerige hacks. De tekortkomingen zijn aangekaart. De ambiguiteit is aangetoond. Wat wil je nu nog horen? Gebruik het commentaar gewoon om je systeem te verbeteren ipv wat je nu doet.

[sarcasme-optima-forma]
Je hebt echt een fantastisch systeem bedacht, ik kan niet wachten op de eerste versie! Top man, ga zo door!
[/sarcasme-optima-forma]

[Creepy]

Verwijderd schreef op woensdag 13 april 2005 @ 19:32:
[...]
BASE64? Hacks? Wat let je om INI files binair te openen (nadat het andere erin is gezet) en op de juiste plaats het in te voegen?

Het feit dat het dan niet meer met een normale tekst editor te bewerken is en je hierdoor de "overzichtelijkheid" t.o.v. van andere opslag formaten verliest.

Ik ga een hele zooi verschillende toepassingen ontwerpen. Ik heb nu al 1001 ideen. Zal ik die posten? Dan ga ik prompt over de 64K heen DBFS is een FileSystem, en werkt als een FileSystem, alleen de interne structuur is als een database, net als in WinFS. Ook kun je DBFS prima gebruiken om bijvoorbeeld een muziekcollectie te ordenen in een logische directorystructuur. In de Directory/File INI's (met dbfsraw of een tooltje dat ik moet devven), kun je een sectie opnemen zoals ``DBInfo'':

En je gaat dus een los filesysteem opslaan in ini files (die al in een filesysteem staat). Zelfs met een blockdevice blijft het een extra laag

code:

<header volgens de IniDB-standaard>
<filesystem-specifieke informatie>

[DBInfo]
Artiest=<artiest>
NummerOpCd=<nummeropcd>
Album=<album>
<zoveel zooi als je wilt>

[PhysicalData]
<de file zelf>

Daar ga ik ook wat voor devven zodat het een point-en-click oplossing wordt, of zo je wilt, een database editor.

Je gaat op deze manier nooit een fatsoenlijk snelheid halen met een flink aantal records. Nogmaals: er is een reden waarom DB's niet op inifiles werken en waarom bijv. ook XML gebaseerde databases met opzoeken aan de trage kant zijn

Jep, maar die werken niet met een standaard die volgens vaste specificaties werkt en toch zo uitbreidbaar is

Dat geld voor jou iniDB ook: Iedereen mag z'n eigen implementatie doen. Config files worden per app dus verschillend en is er geen vaste specificatie meer.

[b]Implementaties[b] zei ik, geen interpretaties. Daar is een verschil tussen. De basisstructuur van de INI wordt gedefineerd. Zolang het daaraan voldoet, mag een app zijn data op elke manier wegschrijven die de programmeur wil. Je hebt HTML 4 Strict, en alle browsers moeten eraan voldoen. Al doen ze dat bij HTML niet, bij zoiets eenvoudigs als IniDB verwacht ik wel dat ze zich aan de (zeer losse) standaard houden.

Ze moeten zich aan een standaard houden, maar mogen het uitbreiden zoals ze willen... Er blijven dus verschillen en er is geen eenduidige manier om de boel te bekijken of te bewerken. Weg voordeel..

Tja, ik denk daar dus anders over. INI-bestanden zijn geen probleem om uit te breiden met meer attributen. Je hoeft er geen extra ruimte ervoor te reserveren.

De meest uitgebreide versie van de structuur van IniDB is simpel:

code:

; IniDB Example File

[General]
FileRevision=0
IniDBRevision=1

[INIClasses]
System=system/ini.ini
Applications=applications/ini.ini

[Class:SubClass]
Class:SubClass:Setting0=1
Class:SubClass:Attribute55:Value=bar

[IniDB.InterruptParsing]
LineToResumeParsing=22

BAGATGSRHRHREHBG%#QEYGHB&U5tjk46hbnwyhbst
uyetJN^$tjafu5herjnh35qj46qh6
%uhbu5lk75jk767565657ku57kw57k7kw576ke8k64l784l4757jnqy7j53j373733762hbr6s7yjn54e

[Class:SubClass]
Class:SubClass:Setting1=1
Class:SubClass:Attribute54:Value=blaatkoe

Zoals je ziet, is het eenvoudig om nog extra info te appenden in de INI. Zo kun je ook een instelling veranderen in 1 die langer is dan de vorige zonder het bestand op te schuiven. Alle secties met dezelfde naam worden als 1 sectie gezien. Op een gegeven moment wordt dit gefragmenteerd, maar in een zeer korte periode kan dit worden rechtgezet. Een beetje schuiven met de data en het is weer op orde.

Waar heb je het over? Extra data appenden aan een file kan atijd. Nu wil ik Class:SubClass:Setting1 langer maken (12-93328123897 i.p.v. 1). Wat nu? Voor de twee keer een setting1 aanmaken? Dan zijn er twee, welke is nu de correcte? Altijd de laatste? Dan moet je nu ineens de gehele file gaan doorzoeken naar de juiste instelling

of toch "gewoon" langer maken en de file opnieuw wegschrijven? Prima, maar waarom heb je het dan over makkelijk appenden?

[.oisyn]

Creepy schreef op donderdag 14 april 2005 @ 11:41:
En je gaat dus een los filesysteem opslaan in ini files (die al in een filesysteem staat). Zelfs met een blockdevice blijft het een extra laag

Idd, ik vind het wel komisch om te lezen hoe je (De Zeurkous) in het andere topic uitgelegt dat lagen niet goed zijn voor de efficientie, en vervolgens met zo'n systeem komt voor het opslaan van files met metadata

[Verwijderd]

Verwijderd schreef op donderdag 14 april 2005 @ 11:37:
[...]
De bzwaren zijn gemaakt, je hebt ze weerlegt met smerige hacks. De tekortkomingen zijn aangekaart. De ambiguiteit is aangetoond. Wat wil je nu nog horen? Gebruik het commentaar gewoon om je systeem te verbeteren ipv wat je nu doet

Heb ik niet het meeste al aangepast naar jullie commentaar? Dat doe ik en blijf ik doen. Als jullie het systeem niet willen gebruiken: Ok, dat is jullie keuze. Iedereen is daar vrij in. Maar ik ben wel blij met kritiek om het systeem te verbeteren.

[sarcasme-optima-forma]
Je hebt echt een fantastisch systeem bedacht, ik kan niet wachten op de eerste versie! Top man, ga zo door!
[/sarcasme-optima-forma]

[van de domme houden]
Dankjewel! $me dacht dat zijn systeem (zoals elk systeem) niet optimaal was, maar blijkbaar zijn er toch mensen die het fantastisch vinden!
[/van de domme houden]

[Verwijderd]

Creepy schreef op donderdag 14 april 2005 @ 11:41:
[...]

Het feit dat het dan niet meer met een normale tekst editor te bewerken is en je hierdoor de "overzichtelijkheid" t.o.v. van andere opslag formaten verliest.

De specificatie zal daarom aangeven dat als het bestand binaire data bevat (en het wordt aangeraden die data er alleen in te plaatsen wanneer het absoluut nodig is) moet die helemaal onderaan staan. Dus:

code:

[IniDB.InterruptParsing]
ByteToResumeParsing=<byte>

<binaire data>

<verdergaan met .INI structuur>

wordt:

code:

<INI-structuur>
[IniDB.StopParsing]

<binaire data>

[...]

En je gaat dus een los filesysteem opslaan in ini files (die al in een filesysteem staat). Zelfs met een blockdevice blijft het een extra laag

Nee. De INI Files staan als 1 stroom data in dat block device. Geen filesystem op dat niveau dus.

[...]

Je gaat op deze manier nooit een fatsoenlijk snelheid halen met een flink aantal records. Nogmaals: er is een reden waarom DB's niet op inifiles werken en waarom bijv. ook XML gebaseerde databases met opzoeken aan de trage kant zijn

Alleen de attributen van de bestanden die nodig zijn en gewenst zijn door de gevorderde gebruiker staan in de INI structuur.

code:

<gewone IniDB data, heel weinig dus>

[FileFragments]
Fragments=<numfragments>
Fragment<nummer>=<eerste byte>,<laatste byte>
<etc.>

[FileAttributes]
<naam, locatie, etc.>

[IniDB.EndParse]

<eerste (kleine) fragment van data>

Een volgende fragment is gewone pure binaire data en niet INI.

[...]

Dat geld voor jou iniDB ook: Iedereen mag z'n eigen implementatie doen. Config files worden per app dus verschillend en is er geen vaste specificatie meer.

De IniDB standaard is er alleen om te definieren hoe om te gaan met de header, secties, classes, attributen, embedded (binaire) data, etc. Daarop ga ik toch nog verschillende standaarden (natuurlijk met bijbhorende utils) schrijven. Zoals DBFS. IniDB is een basis, daarop kun je (en dat zal ik doen) verder bouwen.

[...]

Ze moeten zich aan een standaard houden, maar mogen het uitbreiden zoals ze willen... Er blijven dus verschillen en er is geen eenduidige manier om de boel te bekijken of te bewerken. Weg voordeel..

Die is er dus wel. En voor een aantal van die uitbreidingen ga ik ook standaarden schrijven.

[...]

Waar heb je het over? Extra data appenden aan een file kan atijd. Nu wil ik Class:SubClass:Setting1 langer maken (12-93328123897 i.p.v. 1). Wat nu? Voor de twee keer een setting1 aanmaken? Dan zijn er twee, welke is nu de correcte? Altijd de laatste? Dan moet je nu ineens de gehele file gaan doorzoeken naar de juiste instelling

Dat is dus al achterhaald Bovendien, als ik dit zou gebruiken (wat ik dus niet doe), dan moet de eerste instelling verwijderd worden. Maar dat is nog steeds inefficient. Zie bovenstaand.

of toch "gewoon" langer maken en de file opnieuw wegschrijven? Prima, maar waarom heb je het dan over makkelijk appenden?

Precies. Geen ``makkelijk appenden'' dus, ipv dat bovenstaand.

[ Voor 6% gewijzigd door Verwijderd op 14-04-2005 13:01 ]

[Verwijderd]

.oisyn schreef op donderdag 14 april 2005 @ 11:51:
[...]


Idd, ik vind het wel komisch om te lezen hoe je (De Zeurkous) in het andere topic uitgelegt dat lagen niet goed zijn voor de efficientie, en vervolgens met zo'n systeem komt voor het opslaan van files met metadata

Ik bedoelde (in dat andere topic) met ``lagen'' geen lagen in de standaard, maar in de _implementatie_. Daar is een groot verschil tussen. Mijn implementaties zullen gewoon de complete IniDB-standaard _zelf_ afhandelen. Geen lagen dus.

[.oisyn]

Je lagen zitten nog altijd in het feit dat je een filesystem implementeert als text-based files op een filesystem. En hoe gaat jouw implementatie interfacen met die files dan, heb je je eigen hdd drivers geschreven? Nee, dat doe via een library (waarschijnlijk diegene die bij je programmeertaal zit, die op zijn beurt weer interfaced met OS calls, wat weer door een HAL laag gaat, vervolgens naar de driver, etc.)

[Verwijderd]

.oisyn schreef op donderdag 14 april 2005 @ 13:20:
Je lagen zitten nog altijd in het feit dat je een filesystem implementeert als text-based files op een filesystem. En hoe gaat jouw implementatie interfacen met die files dan, heb je je eigen hdd drivers geschreven? Nee, dat doe via een library (waarschijnlijk diegene die bij je programmeertaal zit, die op zijn beurt weer interfaced met OS calls, wat weer door een HAL laag gaat, vervolgens naar de driver, etc.)

Het is niet:

code:

Files > FileSystem > INI > FileSystem

maar:

code:

Files > FileSystem > INI > Rauwe Binaire Datastroom > Block Device

Bovendien ga ik zoveel mogelijk calls zelf schrijven en/of kopieren en aanpassen uit GPL libraries. Maar, zoals ik ook in het andere topic zei: De Kernel Is Een Geval Apart. Alles gaat gewoon door de kernel, maar niet door lagen erboven

[Gerco]

Ik wil niet vervelend zijn, maar je zegt dus dat je de file opnieuw moet schrijven als er halverwege iets veranderd, dat klopt. Even verderop stel je dat je die ini data zonder file structuur op een block device gaat schrijven.

Op die manier moet je als ik ergens in het begin een setting verander de HELE blockdevice, maw alle settings van alle apps (vergelijk: de hele registry) opnieuw wegschrijven, het is immers 1 "ruwe stroom data".

Niet alleen is dit een slecht idee uit data integrity en uit schijf slijtage oogpunt, maar het is ook nogeens volkomen onschaalbaar. Met slechts enkele tientallen applicaties gaat het veranderen van een setting al ordes van grootte langer duren dan met een echt db formaat. Waarom denk je dat XML files zo traag zijn voor dit soort doeleinden, regel gebaseerde formaten zijn gewoon niet snel, punt.

offtopic:
Ik dacht dat het hier Programming & Webscripting heette, niet Speculating & Hallucinating

[ Voor 13% gewijzigd door Gerco op 14-04-2005 13:54 ]

[Verwijderd]

Ik ben het eens met de opmerkingen die al gemaakt zijn:

De programmeurs op GoT proberen aan te tonen dat je systeem niet goed overdacht is. Op elk voorbeeld van een probleem waar je tegenaan kan lopen bedenk jij vervolgens een workaround (nee, geen oplossing dus!) die dat geval wel mogelijk maakt.

Het uiteindelijke resultaat is waarscshijnlijk dat je hele systeem houtje-touwtje aan elkaar hangt, en godsellendig traag is. Waarom zou iemand het dan nog gebruiken? Omdat jij het gemaakt hebt?

Voor alle serieuze en minder serieuze applicaties is het op dat moment waarschijnlijk efficiënter iets customs te gebruiken wat precies voldoet aan de eisen van die applicatie (en niet meer, zoals dat systeem van jou), zodat er geen onnodige overhead bij komt.

Wat ik maar wil zeggen: begin opnieuw of geef het op.
Tip(1): Stel een duidelijke lijst op van wat je wilt bereiken (dus wat je systeem moet kunnen, en -- ook heel belangrijk -- wat het niet moet/hoeft te kunnen), en controleer achteraf of wat je bedacht hebt daaraan voldoet.
Tip(2): INI files zijn niet het begin en einde van de wereld. Je kunt ook zelf een opslagformaat bedenken en daar een parser voor schrijven.

[ Voor 4% gewijzigd door Verwijderd op 14-04-2005 14:02 ]

[Verwijderd]

Gerco schreef op donderdag 14 april 2005 @ 13:51:
Ik wil niet vervelend zijn, maar je zegt dus dat je de file opnieuw moet schrijven als er halverwege iets veranderd, dat klopt. Even verderop stel je dat je die ini data zonder file structuur op een block device gaat schrijven.

Dat is precies wat ik zei.

Op die manier moet je als ik ergens in het begin een setting verander de HELE blockdevice, maw alle settings van alle apps (vergelijk: de hele registry) opnieuw wegschrijven, het is immers 1 "ruwe stroom data".

Nee. Daarvoor heb je de Fragments Zodra er niet genoeg meer is voor uitbreiding van de huidige INI, zoekt hij een zo dicht mogelijke lege byterange op en gaat daar verder.

Niet alleen is dit een slecht idee uit data integrity en uit schijf slijtage oogpunt, maar het is ook nogeens volkomen onschaalbaar. Met slechts enkele tientallen applicaties gaat het veranderen van een setting al ordes van grootte langer duren dan met een echt db formaat. Waarom denk je dat XML files zo traag zijn voor dit soort doeleinden, regel gebaseerde formaten zijn gewoon niet snel, punt.

Onschaalbaar? Waar haal je dat idee vandaan? Het is namelijk geen enkel probleem het filesystem met extra ruimte uit te breiden. Gewoon vrijmaken en in de root INI opgeven. En zoals ik al zei, begint die direct na de header

offtopic:
Ik dacht dat het hier Programming & Webscripting heette, niet Speculating & Hallucinating

Dit is niet speculating. Dit is debuggen. Zodra het niet blijkt te voldoen, pas je het aan. Ontdek je weer een bug, fix je die weer. Daar is geen speculatie of hallucinatie aan.

[ Voor 3% gewijzigd door Verwijderd op 14-04-2005 14:52 ]

[whoami]

Waar hier over gepraat wordt, zijn geen 'bugs', maar ontwerpfouten.
Da's nog heel wat anders. Een bug is als je iets geimplementeerd hebt (geprogrammeerd) dus, maar het voldoet niet a/d specs; ergo, het levert onjuiste informatie af.

Hier wordt er alleen nog maar over het 'ontwerp' gepraat, dus die dingen zijn ontwerpfouten, geen bugs.

[Verwijderd]

Verwijderd schreef op donderdag 14 april 2005 @ 14:01:
Ik ben het eens met de opmerkingen die al gemaakt zijn:

De programmeurs op GoT proberen aan te tonen dat je systeem niet goed overdacht is. Op elk voorbeeld van een probleem waar je tegenaan kan lopen bedenk jij vervolgens een workaround (nee, geen oplossing dus!) die dat geval wel mogelijk maakt.

Dan kun je ook een driver zien als een workaround omdat het niet mogelijk is om raw te schrijven en andere apps tevreden te houden.

Het uiteindelijke resultaat is waarscshijnlijk dat je hele systeem houtje-touwtje aan elkaar hangt, en godsellendig traag is. Waarom zou iemand het dan nog gebruiken? Omdat jij het gemaakt hebt?

Nee. Linus Thorvalds heeft Linux gemaakt en ik gebruikt het daarom niet, maar omdat het goed voldoet aan mijn eisen.

Voor alle serieuze en minder serieuze applicaties is het op dat moment waarschijnlijk efficiënter iets customs te gebruiken wat precies voldoet aan de eisen van die applicatie (en niet meer, zoals dat systeem van jou), zodat er geen onnodige overhead bij komt.

Owkee, dus jij schrijft ook alles direct naar een partitie ipv een filesystem omdat het efficienter is?

Wat ik maar wil zeggen: begin opnieuw of geef het op.
Tip(1): Stel een duidelijke lijst op van wat je wilt bereiken (dus wat je systeem moet kunnen, en -- ook heel belangrijk -- wat het niet moet/hoeft te kunnen), en controleer achteraf of wat je bedacht hebt daaraan voldoet.

$me heeft al zo'n lijst, en past hem steeds aan zodra iemand met een belangrijke eis komt. Mijn filesystem moet veel, maar om op een of andere rare manier het geheugen van de printer te gebruiken voor opslag is niet nodig

Tip(2): INI files zijn niet het begin en einde van de wereld. Je kunt ook zelf een opslagformaat bedenken en daar een parser voor schrijven.

Klopt. Het is _een_ begin. Je hebt God en Allah en toch stellen ze allebij een groep mensen tevreden.

[Verwijderd]

whoami schreef op donderdag 14 april 2005 @ 14:53:
Waar hier over gepraat wordt, zijn geen 'bugs', maar ontwerpfouten.
Da's nog heel wat anders. Een bug is als je iets geimplementeerd hebt (geprogrammeerd) dus, maar het voldoet niet a/d specs; ergo, het levert onjuiste informatie af.
Hier wordt er alleen nog maar over het 'ontwerp' gepraat, dus die dingen zijn ontwerpfouten, geen bugs.

Dan heb ik een vrijere intrepretatie van wat een bug is Je kunt stellen dat je een plaatje hebt geprogrammeerd ipv getekend. Je geeft informatie op (aan de computer, of een potlood en papier), en door de magische reactie van de computer of het potlood op het papier wordt het een tekening. Als je het potlood / de muis verkeerd beweegt, geef je onjuiste informatie op en ziet het plaatje er lelijker uit dan bedoeld is.

[whoami]

Goh ja....

[Gerco]

Met alle respect "De Zeurkous", ik denk niet dat je erg ver gaat komen door de programmeurs op GoT om advies te vragen omtrend dit systeem. Er zijn namelijk twee mogelijkheden die me direct te binnen schieten:

1. Je systeem kan werken, maar het is zo anders dan wat we gewend zijn dat wij te conservatief zijn ingesteld om er objectieve kritiek op te leveren.
2. Je systeem raakt kant noch wal, leuk gedachtenexperiment, maar het gaat nergens heen.

Welke interpretatie je kiest moet je zelf weten, maar in beide gevallen ben je beter af om je systeem gewoon te maken en te zien wat voor problemen je eventueel tegen het lijf loopt. Nogmaals, ik zou het graag zien werken als het af is, ik ben altijd wel in voor een curiositeit.

Ik denk dat je in je implementatiefase tegen zoveel issues aan gaat lopen dat het uiteindelijk nooit gaat werken, maar dat zul je overduidelijk niet inzien tot je het zelf probeert. Daar is niets mis mee, we moeten allemaal eens vallen, maar doe het dan ook gewoon en kijk hoever je komt.

[ Voor 18% gewijzigd door Gerco op 14-04-2005 15:29 ]

[Verwijderd]

Gerco schreef op donderdag 14 april 2005 @ 15:17:
Met alle respect "De Zeurkous", ik denk niet dat je erg ver gaat komen door de programmeurs op GoT om advies te vragen omtrend dit systeem.

$me's gedachten over dit topic gingen ook al in die richting...

Er zijn namelijk twee mogelijkheden die me direct te binnen schieten:

1. Je systeem kan werken, maar het is zo anders dan wat we gewend zijn dat wij te conservatief zijn ingesteld om er objectieve kritiek op te leveren.
2. Je systeem raakt kant noch wal, leuk gedachtenexperiment, maar het gaat nergens heen.

Daar kan ik pas een beslissing over maken als ik een implementatie voor de standaard heb geschreven. Misschien kan ik dan daar maar beter aan beginnen

Welke interpretatie je kiest moet je zelf weten, maar in beide gevallen ben je beter af om je systeem gewoon te maken en te zien wat voor problemen je eventueel tegen het lijf loopt. Nogmaals, ik zou het graag zien werken als het af is, ik ben altijd wel in voor een curiositeit.

Je hebt gelijk. Dan stel ik een stilte voor in dit topic tot ik de eerste versie van mijn implementatie klaar heb. Geen slotje, dat vindt ik te permanent, want zodra de implementatie klaar is moet iedereen wel kunnen zien waar het allemaal vandaan komt

Bedankt allemaal!

/me pakt een fles cola en gaat pr0ggen

[Voutloos]

Verwijderd schreef op donderdag 14 april 2005 @ 15:00:
$me heeft al zo'n lijst, en past hem steeds aan zodra iemand met een belangrijke eis komt. Mijn filesystem moet veel, maar om op een of andere rare manier het geheugen van de printer te gebruiken voor opslag is niet nodig

Uiteraard mag er best wel eens een grapje gemaakt worden, maar volgens mij ben jij echt niet serieus met je "Won't haves" van je programma.
Een MoSCoW (Must have, Should have, Could have, Won't have) lijstje mag misschien wat kinderachtige/betuttelend klinken, maar het lijkt me echt een goed idee als jij zoeits maakt. Je bent nogal enthousiast in het willen programmeren (wat op zich geen ramp is ) en je onderschat imo een aantal zaken behoorlijk, dus als jij zonder concrete doelen gaat proggen, ga je volgens mij alleen maar rare details erbij trekken tot je totaal verdwaald raakt in wat je eigenlijk allemaal wel niet wil en een onbruikbare hoop code overhoudt.

Maar goed, oefening baart kunst en misschien is een eerste implementatiefase of -poging wel de manier voor jou om achter je designfouten te komen. Dus leef je dan maar uit.
_{En laten we alsjeblieft designfouten designfouten noemen en bugs bugs.}

Dat ik wat sceptisch tegen je project aankijk, betekent zeker niet dat ik te zijner tijd niet geïnteresseerd ben in geboekte resultaten.

[ Voor 12% gewijzigd door Voutloos op 14-04-2005 17:16 ]

[Orphix]

* Orphix komt De Zeurkous persoonlijk een kratje bier brengen als het klaar is (of kratje cola)

[.oisyn]

Voutloos schreef op donderdag 14 april 2005 @ 17:08:
MoSCoW (Must have, Should have, Could have, Won't have)

Hmm, da's weer een ander dialect, ik heb op school ooit geleerd dat die W stond voor Would be nice . Een won't have lijkt me wat dat betreft nutteloos, aangezien iets dat niet in de rest van de lijstjes staat automatisch niet meetelt. Maar goed, dat is offtopic

[NMe]

.oisyn schreef op donderdag 14 april 2005 @ 17:37:
Hmm, da's weer een ander dialect, ik heb op school ooit geleerd dat die W stond voor Would be nice . Een won't have lijkt me wat dat betreft nutteloos, aangezien iets dat niet in de rest van de lijstjes staat automatisch niet meetelt. Maar goed, dat is offtopic

Iets dat niet in die lijstjes staat kan simpelweg een vergeten puntje zijn. Wanneer je het als Won't have opgeeft, dan geef je specifiek aan dat het niet gaat gebeuren. Nuanceverschil dus.

[Voutloos]

offtopic:
OK, volledig is het inderdaad "Won't have this time but would like to have in the future." Sorry, mijn Russisch was iets weggezakt. Waar het om gaat is dat je dingen durft te noemen (welke wel serieus te overwegen zijn, vandaar dat ik viel over het printergeheugengrapje) welke je voorlopig niet wil hebben.

[ Voor 28% gewijzigd door Voutloos op 14-04-2005 17:47 ]

[Zoijar]

"Won't have" kan ook iets aangeven waar je over kan twijfelen in de context, maar er niet in moet. Ik denk bijvoorbeeld aan thread safety bij het ontwikkelen van een library. Programmeurs zouden kunnen vragen "moeten mijn functies thread safe zijn?" Of bv een multi-user omgeving; "kunnen er meerdere mensen tegelijk mee werken?". Dan is het wel handig als die dingen expliciet bij won't have staan.

[Gomez12]

* Gomez12 is even heel erg benieuwd hoe het lijstje wat hij nu heeft zich verhoudt tot topicstart.

Want ik heb al heel veel valide punten gezien waarom het niet goed (gaat) werken, en hier heel veel uitbreidingen van TS voor gezien, maar ik heb altijd geleerd eerst denken dan doen. En als jij een specificatie maakt en deze wordt zo snel en zo veel ( naar mijn idee ) veranderd, dan moet je misschien ergens anders over gaan nadenken, want dan vergeet je gewoon dingen die andere mensen normaal vinden.

[D4Skunk]

*kuch* Schopje *kuch*

Kan ik al ergens een demo downloaden ?

[riezebosch]

Voutloos schreef op donderdag 14 april 2005 @ 17:45:

offtopic:
OK, volledig is het inderdaad "Won't have this time but would like to have in the future." Sorry, mijn Russisch was iets weggezakt. Waar het om gaat is dat je dingen durft te noemen (welke wel serieus te overwegen zijn, vandaar dat ik viel over het printergeheugengrapje) welke je voorlopig niet wil hebben.

offtopic:
Vandaar dat bij bij ons de W niet voor Won't maar voor Would stond (in de zin van: moet, zou moeten, zou kunnen, zou willlen).

[whoami]

modbreak:
mja, misschien is het handiger om dit topic gewoon te laten afzakken.
De Zeurkous zal dit topic wel aanvullen mocht hij een en ander werkend hebben.

[Alarmnummer]

D4Skunk schreef op dinsdag 24 mei 2005 @ 18:04:
*kuch* Schopje *kuch*

Kan ik al ergens een demo downloaden ?

Uhhh... wou je toch niet serieus gaan gebruiken... De TS heeft duidelijk zijn eigen wil en probeert alles op zijn eigen manier op te lossen. Als hij een gedegen opleiding had gehad met veel ervaring had ik hem misschien het voordeel van de twijfel gegeven.

[ Voor 40% gewijzigd door Alarmnummer op 25-05-2005 09:34 ]

[snooze]

als argument werdt genoemd dat als een bestand verplaatst wordt dit enkel in een master ini hoeft te worden gewijzigd, om hier even op door te gaan wat als dit nou vervangen wordt door een dns achtige structuur waar een programma gaat kijken op de verwachte locatie van een bestand pas als hij deze niet kan vinden gaat hij in de master ini kijken waar hij dan moet zijn, uiteraard zou ook die master ini bijgehouden moeten worden wat ook weer de nodige complicaties ivm versies rechten etc met zich meebrengt maar het is het bekijken waard denk ik.

[BigDplayboy]

Nou, ik kwam hier bij uit vanuit een nieuwsartikel
Ik ben benieuwd of de bedenker / Zeurkous na 5 jaar inmiddels een implementatie heeft?

[NMe]

Die heeft zichzelf geband door zijn account te deactiveren dus het lijkt me vrij sterk dat hij dat hier nog komt melden.

[Cypher87]

Toch wel een heerlijk topic om door te lezen Maakt mijn dag weer goed.

[RobIII]

Cypher87 schreef op dinsdag 29 juni 2010 @ 21:00:
Toch wel een heerlijk topic om door te lezen Maakt mijn dag weer goed.

Laten we het op read-only zetten dan
Mag ook wel na ruim 5 jaar. Er staat al een groene schimmel op