Menu
▾
▴
Re: [Jmove-devel] ModelSerialization
|
From: Michael <mj...@we...> - 2005-05-30 18:40:20
|
Hi Axel, grunds=C3=A4tzlich teile ich deine Pr=C3=A4ferenzen f=C3=BCr B und D. Aufgr= und=20 unserer Planungen w=C3=BCrde ich allerdings das aufwand=C3=A4rmere D=20 bevorzugen. Die Idee "Projektdatei" finde ich klasse, denn dadurch=20 wird nichts vorgegaukelt. Mein Vorschlag f=C3=BCr die konkrete Benennung: * load/save module compilation * load/save module set Wir sollten unser Men=C3=BCstruktur daf=C3=BCr weiter standardisieren. Wie = w=C3=A4re=20 es mit=20 Model New Add module ----------------- Load module compilation Save module compilation ----------------- Export XMI ----------------- Quit View Search types //Create diagram //Create report =09 Help Contents About Bzgl. der mittelfristigen Variante B w=C3=BCrde ich in der Tat ein=20 textbasierte Format (gerne XML) verwenden, dann sind Fehler leichter=20 nachvollziehbar und mit entsprechender Komprimierung sollte auch=20 Speicherplatz weniger ein Problem sein. Prinzipiell halte ich XMI f=C3=BCr= =20 zu =C3=BCberfrachtet, unser schmales Kernmodell bietet sicherlich eine=20 effizientere Serialisierungsm=C3=B6glichkeit. Allerdings wenn wir auch=20 Diagramme ablegen wollen... Apropos Diagramme: Es w=C3=A4re super, wenn man Diagramme selbst best=C3=BC= cken=20 k=C3=B6nnte: neues Diagramm anlegen, Packages in das Diagramm ziehen,=20 Abh=C3=A4ngigkeiten werden eingetragen, das Diagramm kann gedruckt=20 werden....megacool! ;-) Gru=C3=9F Michael Am Montag, 30. Mai 2005 11:31 schrieb ax...@sp...: > Hi Michael, > > da bist du aber wieder mal fleissig gewesen :-). Ich habe zumindest > etwas Zeit gefunden deine Sachen auszubrobieren. Den Stack-Overflow > habe ich allerdings noch nicht gefunden - nun ist es aber doch > raus... ;-) > > >Hi, > > > >f=C3=BCr das Speichern und Laden von Modellen habe ich im ersten Ansatz > > die die Standard-Java-Serialisierung verwendet. Dabei ist mir > > Folgendes aufgefallen: > > > >* Viel "implements Serializable" > >* Einige Attribute auf "transient" umgestellt > >* StackOverflowError bei Abspeichern des jmove-source-Modells > > > >Strukturell ist mir aufgefallen, dass unsere abgespeicherten > > Modelle nicht transportf=C3=A4hig sind, da assozierte Locations nach > > einem Laden nicht an der gleichen Stelle liegen m=C3=BC=C3=9Fen und som= it > > Funktionalit=C3=A4t wie Source-Code-Edit nicht funktionieren. > > > >Im Prinzip sehe ich 4 M=C3=B6glichkeiten den Problemen zu begegnen: > > > >A. StackOverflow beheben: Schwierig, weil die Stelle nicht > > verraten wird: ist es einfach die Menge oder erkennt der > >Standard-Java-Mechanismus keine Zyklen? Warum funktioniert das > >Abspeichern und Laden von Byte-Code-Modellen? > > > >B. Eigene Implementierung der Serialisierung: aufwendig aber > >sicherlich passend > > > >C: Nutzung von XStream einer Bibliothek (250KB) zur > > Serialisierung: einfach zu verwenden, aber erzeugte Datenvolumen > > =C3=BCbersteigt wesentlich die Standard-Java-Serialisierung (12MB > > statt 150KB f=C3=BCr Junit), gestiegene Memory-Anforderungen durch > > DOM-Ansatz > >(Jmove-Source-Modell brach mit einer outOfMemory-Excpetion ab) > > > >D: Pseudo-Serialisierung: Serialisierung der Modulpfade und > > erneutes Parsen beim Laden, wenig Aufwand aber schlechte > > Performanz > > > >Was denkt Ihr? > > Also ich denke B + D oder D + B w=C3=A4re Klasse. Ich habe ein bisschen > hin und her =C3=BCberlegt und stelle mir das ungef=C3=A4hr so vor: > > - serialisierte Modellinformationen sind immer dann sinnvoll, wenn > jemand Zeit sparen m=C3=B6chte und Aktualit=C3=A4t nachrangig ist. Beisp= iel: > jemand untersucht einen Release-Stand oder mit jedem Build wird ein > serialisiertes (vorverdautes) Modell erzeugt. > > - wenn Aktualit=C3=A4t im Vordergrund steht, dann arbeite ich lieber auf > dem Source- oder Bytecode. > > - In einem Modell kann es Teile geben, die sich h=C3=A4ufig =C3=A4ndern u= nd > Teile die sich seltener =C3=A4ndern. Man ist also mit unterschiedlichen > Anforderungen an die Aktualit=C3=A4t konfrontiert. > > Ausgehend von dieser Betrachtung kann ich mir folgende L=C3=B6sung > vorstellen: > > - Eine Modelldatei enth=C3=A4lt nur die Modulpfade - also D. Ich w=C3=BC= rde > dies jedoch nicht als Pseudo-Serialisierung bezeichnen. Es ist eher > mit einer Projektdatei einer IDE vergleichbar. > > - ein serialisiertes Modell kann genauso als Modul betrachtet > werden wie ein Source-/Bytecode - Jar/Verzeichnis. Es handelt sich > also nur um eine andere Modulform (und w=C3=BCrde evtl. einen eigenen > Loader erfordern) . > > - es gibt Mechanismen um ein beliebiges Modul in ein serialisiertes > Modul umzuwandeln. > > - Source-(Byte-)Code-Modul + serialisiertes Modul + > Synchronisierung k=C3=B6nnte ein "cached module" sein. > > - wie k=C3=B6nnte man "serialisiertes Modul" nur sinnvollerweise > nennen?!? > > Die Beschr=C3=A4nkung auf die Modulebene macht sicherlich die Anwendung > von B notwendig, f=C3=BCr das es offensichtlich ja auch noch andere > Gr=C3=BCnde gibt. Somit w=C3=BCrde A aussen vor sein. C w=C3=BCrde auch n= icht so > recht in die Betrachtung passen, da meine Annahmen ja davon > ausgehen, dass man Zeit und Speicherplatz sparen m=C3=B6chte. > Grunds=C3=A4tzlich habe ich nichts gegen textbasierte Formate wenn sie > die Anforderung grunds=C3=A4tzlich erf=C3=BCllen. Ein XML-basiertes Format > kann einem sicherlich die Implementierung erleichtern, wenn es > allerdings dadurch zu geschw=C3=A4tzig wird nutzt uns das auch nichts. > Ansonsten k=C3=B6nnten wir keine weiteren grunds=C3=A4tzlichen Vorteile a= us > einem XML-Format ziehen. Speziell ein XMI-Modul w=C3=A4re zwar auch sehr > attraktiv, w=C3=BCrde uns aber im Rahmen dieser Diskussion nicht weiter > bringen. > > Ok - das reicht erst mal. Was meint ihr dazu? > > Ahoi > > Axel > > >Gru=C3=9F > >Michael > > > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by Yahoo. > >Introducing Yahoo! Search Developer Network - Create apps using > > Yahoo! Search APIs Find out how you can build Yahoo! directly > > into your own Applications - visit > > http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22005 > > _______________________________________________ > >Jmove-devel mailing list > >Jmo...@li... > >https://lists.sourceforge.net/lists/listinfo/jmove-devel > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using > Yahoo! Search APIs Find out how you can build Yahoo! directly into > your own Applications - visit > http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22005 > _______________________________________________ > Jmove-devel mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmove-devel |
