94 replies to this topic

[mirakels]

ik heb al wel tijden een lamedb format change klaar liggen om de multi-line entries om te zetten naar een single line per transponder/service. Dat maakt lamedb wel leesbaarder for the naked eye, maar vergt ook aanpassingen aan channeleditors dus daarom nooit publiek gemaakt.

[Rob van der Does]

En ondertussen doen we het met deze structuur al vanaf ergens in 2002....'het begin van de E1 tijd...

Om je eigen woorden uit een ander draadje te citeren: het is niet goed, maar het werkt wel.

Tijd voor navelstaren?

[Rob van der Does]

ik heb al wel tijden een lamedb format change klaar liggen om de multi-line entries om te zetten naar een single line per transponder/service. Dat maakt lamedb wel leesbaarder for the naked eye, maar vergt ook aanpassingen aan channeleditors dus daarom nooit publiek gemaakt.

Maar als ik de discussie goed lees, is leesbaarheid voor de mens van geen belang. Sterker nog: die lokt alleen maar manipulatie uit.

[littlesat]

Mirallas, als het oude formaat nog ingelezen misschien eens zomaar wereldkundig maken

[mirakels]

 

ik heb al wel tijden een lamedb format change klaar liggen om de multi-line entries om te zetten naar een single line per transponder/service. Dat maakt lamedb wel leesbaarder for the naked eye, maar vergt ook aanpassingen aan channeleditors dus daarom nooit publiek gemaakt.

Maar als ik de discussie goed lees, is leesbaarheid voor de mens van geen belang. Sterker nog: die lokt alleen maar manipulatie uit.

 

Als je dan goed gelezen hebt, kan je concluderen dat ik het daar niet direct mee eens ben.

Ik heb al heel veel problemen SNEL kunnen oplossen doordat configuratie gegevens gewoon goed leesbaar waren (wat niet betekent dat je dan ook direct die leesbare filese met de hand moet wijzigen!). En ik weet zeker dat die problemen  niet (zo snel)  opgelost hadden kunnen worden als het een onleesbaar verhaal zou zijn geweest en je de dingen via allerlei wazige applicaties had moeten controleren.

[Erik Slagter]

Er is een wet in de informatica en die zegt dat er iedere 5 jaar een nieuwe hype is. Een zeer wijze les, die helaas zelden als 1e les geleerd wordt, is nooit op die hype te springen, want daar gaan kapitalen in die na een paar jaar waardeloos zijn. In plaats daarvan moet je analyseren welk deel van de hype structureel is en daar op inspringen.

Ik had het niet over hypes. Ben ook wars van "solutions". Ik had het over basis-inzicht wat in 1988 toen ik het leerde gold en nog steeds geldt.

[haneli]

Dank voor al jullie bijdragen. Het lukt me in eerste instantie ook niet. Ik deed een fastscan bij Canal Digital en hij vond inderdaad nieuwe zenders maar ik kreeg maar geen beeld. Heb toen als leek van alles zitten klooien....ook niet erg handig natuurlijk en uiteindelijk gewoon de spanning van de VU afgehaald en opnieuw opgestart en tot mijn eigen stomme verbazing ( want ik ben ECHT een leek) kreeg ik plotseling gewoon weer NPO1 etc etc. en ben vooral helemaal nergens meer aangekomen, ook neemt hij gewoon weer prima op.

Wat een ontzettend goede 'technicus' ben ik toch ;-)))

 

dank....Hans

[Zuppelan]

Als je dan goed gelezen hebt, kan je concluderen dat ik het daar niet direct mee eens ben.
Ik heb al heel veel problemen SNEL kunnen oplossen doordat configuratie gegevens gewoon goed leesbaar waren (wat niet betekent dat je dan ook direct die leesbare filese met de hand moet wijzigen!). En ik weet zeker dat die problemen  niet (zo snel)  opgelost hadden kunnen worden als het een onleesbaar verhaal zou zijn geweest en je de dingen via allerlei wazige applicaties had moeten controleren.

Kijk, op zich ben ik het er helemaal mee eens dat tekstbestanden toegankelijk zijn, maar ik denk dat je ook de vraag moet stellen waarom je met hand in dit soort gegevens wilt kunnen knoeien. Ik denk dat je je dan twee vragen moet stellen:

• Hadden die problemen hoegenaamd wel op kunnen treden bij een solide bandsformaten waarin veel problemen gewoon niet mogelijk zijn?
• Verlies je überhaupt wel iets al je in de toekomst gewoon de juiste gereedschappen hebt om de transponder- en zendertabellen opnieuw te vullen?

[Rob van der Does]

 

 

ik heb al wel tijden een lamedb format change klaar liggen om de multi-line entries om te zetten naar een single line per transponder/service. Dat maakt lamedb wel leesbaarder for the naked eye, maar vergt ook aanpassingen aan channeleditors dus daarom nooit publiek gemaakt.

Maar als ik de discussie goed lees, is leesbaarheid voor de mens van geen belang. Sterker nog: die lokt alleen maar manipulatie uit.

 

Als je dan goed gelezen hebt, kan je concluderen dat ik het daar niet direct mee eens ben.

Ik heb al heel veel problemen SNEL kunnen oplossen doordat configuratie gegevens gewoon goed leesbaar waren (wat niet betekent dat je dan ook direct die leesbare filese met de hand moet wijzigen!). En ik weet zeker dat die problemen  niet (zo snel)  opgelost hadden kunnen worden als het een onleesbaar verhaal zou zijn geweest en je de dingen via allerlei wazige applicaties had moeten controleren.

 

Laat ik het dan anders formuleren: welke problemen worden daarmee dan opgelost? Want ik begrijp dat de onderliggende structuur (met meerdere, niet gecorreleerde bestanden) daarmee niet wordt aangepakt; en dat was toch het hoofdissue van deze discussie?

[WanWizard]

Dat was in ieder geval mijn insteek, ja.

 

Er spelen in de huidige architectuur twee grote problemen:

- data staat in losse XML files die door externe tools (en/of hun users) bot worden overschreven, waarbij je of informatie kwijtraakt (door overschijving) of informatie verminkt raakt (door foutieve informatie).

- data in verschillende losse XML files is onderling gerelateerd, maar dat wordt nergens afgedwongen en gevalideerd (in rdbms termen: constraints), waardoor je discrepanties kunt krijgen.

 

Bij het tweede punt speelt dan ook nog dat je veel code nodig hebt om alles "handmatig" in sync te houden, en om allerlei sync fouten af te vangen (bijvoorbeeld als je de ene file wel vervangt en de andere niet, met een discrepantie tot gevolg).

 

Dat eerste los je op door alleen maar toegang toe te staan door middel van een API, die alle validatie voor zijn rekening neemt. Dat tweede door een opslagmechanisme te implementeren waarin je die constraints wel vast kunt leggen.

 

Het heeft ook nog wel wat meer voordelen:

- je hoeft niet meer allerlei files in te lezen, daarvoor flinke blokken code te hebben (parsers, validatie, interne API, etc).

- je hoeft al die data niet meer constant in memory te houden (gebeurt nu om de snelheid acceptabel te houden, omdat het vorige punt rete-traag is).

- je kunt discrepanties (denk aan bijvoorbeeld de N/A in je zenderlijst na een scan) beter detecteren / aanpassen / oplossen / afhandelen.

- je kunt nu ongerelateerde data relateren (denk bijvoorbeeld aan zenderljst -> EPG data).

 

En daarnaast kun je nog meer leuke dingen doen: Wat dacht je bijvoorbeeld van de timer.xml. Stop die er ook in, stop ook de autotimer config er in, en maak autotimer functionaliteit die door middel van een stored procedure zorgt dat dynamisch je timer lijst wordt bijgewerkt.

 

Of een Enigma IPTV oplossing waarmee je je stream-doosjes laat praten met deze API in plaats van de lokale API, zodat je remote zapt met info uit de correcte database, je timers ook direct in de juiste database maakt, je altijd in sync bent met de donor box, etc.

 

Ik denk dat als we er voor gaan zitten, dit het topje van de ijsberg is...

[Rob van der Does]

Ik denk dat als we er voor gaan zitten, dit het topje van de ijsberg is...

Dat is bij elke nieuwe systeemarchitectuur het geval; maar wel een noodzakelijke voorwaarde om tot een goed concept te komen. Tijd die je nu daaraan besteedt, bespaart je later een veelvoud daarvan.

[WanWizard]

Helemaal eens.

 

Het is dat zowel mijn C++ als mijn Pyhton kennis quasi onbestaande is, anders was ik er al lang aan begonnen.

[Rob van der Does]

Als er eenmaal een duidelijke structuur is afgesproken, waar liefste de meeste ontwikkelaars achter staan, komt er vanzelf wel een liefhebber bovendrijven om het uit te voeren.
Meestal is het systeemontwerp het meeste werk, en daarvoor is geen codeerkennis nodig.

[mirakels]

@ zuppelan en Rob van der does,

Ik had het niet specifiek over de lamedb en satellites.xml, maar in zijn algemeenheid, ook buiten de sateliet wereld om.

 

en ik moet de eerste 'solide' bestandsformaat nog tegen komen (bij wijze van spreken dan). Het probleem is juist vaak dat de applicatie over de zeik gaat doordat er ergens in die applicatie iets misgaat waardoor dat solide bestandsformaat wat vreemd gevuld kan worden. Dat heet bugs, en als de applicatie zover is dat hij niet goed meer met zijn bestand om kan gaan is het handig dat je er een menselijk oog op kan laten schijnen.

Nogmaals allemaal in zin algemeenheid; misschien niet van toepassing op het bewuste onderwerp...

[Rob van der Does]

Volgens mij wordt het tijd om de off-topic zaken naar een apart draadje te verhuizen