[done] DEC class xy not found

[negaH]

Zitat:

Warum eigentlich #$5A und nicht einfach 'Z' ?

Kannst du erkennen das im Zeichen Z das oberste Nibble 0101b=$5 und das unterste Nibble 1010b=$A ist ?

Es wird also deshalb #$5A benutzt weil es um die binäre Codierung hier geht die der Programmierer benutzen möchte. Ich nenne es "explizite Programmierung" und deren Ziel ist die Reproduzierbarkeit der Sourcen im Kopf anderer Programmierer.

Gruß Hagen

[himitsu]

Jetzt wo du's sagst ... daran hatte ich garnicht gedacht (hatte nur beim Anblick des Wertes das Z vor Augen)
aber stimmt, dann ist es so natürlich besser.


Schade, daß es in Delphi keine Binärdarstellung gibt.

[negaH]

nochwas zum Thema .Identity im DEC. Das ist eine der Stellen dir mir so garnicht noch nie richtig gefallen hat
Die zu lösende Problematik ist eine möglichst kurze aber eineindeutige ID zu jeder Klasse im DEC zu schaffen. Wichtig dabei ist aber noch das man mit der Änderung von DECUtil.IdentityBase alle IDs serialisieren kann. Dh. je nach Anwendung kann der Programmierer über IdentityBase das ID System individualisieren auf ein Projekt ohne das man den kompletten Source ändern muß.

Man speichert also in einem Stream als Header die Identities der benutzten DEC Klassen und danach zb. die verschlüsselten Daten. Bei der Entschlüsselung kann mit DECClassByIdentity() diese registrierte Klasse als Objekt geladen werden. Um diese Header mit fester Länge anlegen zu können wird für Identity ein Cardinal benutzt, statt wie üblich den Klassennamen im Header lesbar zu speichern.

Ein weiteres Kriterium war dabei aber auch das zukünftige neue DEC Klassen voll transparent implementierbar sein müssen ohne das sich der jeweiligen Programmierer mit diesen IDs beschäftigen müssen. Zb. bei Vergabe fester sequentieller IDs für die Klassen müssen die Programmierer sich immer abstimmen und diese IDs dann auch pflegen. Das geht bei einer Bibliothek die weltweit verwendet wird leider nicht mehr zu organisieren.

Jetzt, im nachhinein, würde ich GUIDs dafür benutzen da man damit schon rein mathematisch die Wahrscheinlichkeiten von Kollisionen enorm reduziert. Das jetztige Verfahren birgt ein hohes Risiko von Kollisionen, die aber bei der Registration einer DEC Klasse zuverlässig erkennt werden. Sollte dies der Fall sein muß man entweder den Klassennamen oder IdentityBase ändern.

Wie gesagt, damals viel mir nichts besseres ein und zufrieden bin ich mit dieser Lösung noch heute nicht. Vielleicht fällt ja einem von euch was ein was neu für mich wäre.

Gruß Hagen

[Assertor]

Hallo Hagen,

Zitat von negaH:

Wie gesagt, damals viel mir nichts besseres ein und zufrieden bin ich mit dieser Lösung noch heute nicht. Vielleicht fällt ja einem von euch was ein was neu für mich wäre.

Eine GUID Liste zu führen und abzugeleichen wäre tatsächlich zu aufwendig und fehleranfällig. Eine langsamere Alternative wäre die Nutzung von Hashes, also ein Hash auf Klassenname + IdentityBase. Die verwendete Hash-Klasse könnte dann, wie IdentityBase, änderbar sein und das Default entsprechend Weise gewählt werden. Genauso wie eine GUID bekommt man das natürlich nicht mehr in einem LongWord/Cardinal unter, sondern würde entspreche Wrapper für .Identity als Bytes und zusätzlich z.B. als HEX-String bieten.

Es gäbe dabei aber das Problem der Abwärtskompatibilität, da die jetzige Identity ja auch von Entwicklern genutzt wird. Eine Änderung könnte m.E. nur parallel implementiert werden.

Gruß,
Assertor

P.S.: Meine PN bezgl. 2DES/3DES und Byte Arrays hat sich vollkommen erledigt - läuft alles