[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kuml-devel
Subject:    Fwd: Re: IO subsystem
From:       Darius Stachow <dstachow () ngi ! de>
Date:       2000-06-24 12:25:53
[Download RAW message or body]

Hi

Here comes some information about the new IO subsystem that will be developed
by Geoff Glasson.

----------  Forwarded Message  ----------
Subject: Re: IO subsystem
Date: Tue, 13 Jun 2000 19:54:00 -0400
From: Geoff Glasson <gjg@delenn.glastech.com.au>


Hi Darius,

At this stage I don't believe that there is a need to involve other 
developers in the IO subsystem.  The whole design is still fluid as I will 
explain below, and I think that multiple developers would simply confuse the 
issue.  It is my intention to get the IO subsystem developed, and then use it 
to build a KUML model that describes the IO subsystem.  At that point I think 
that it would be beneficial to get feedback from other developers, because 
they will have something that they can use and critique.

I have been forced to change the way in which KUML models are stored as XML 
files.  As you may be aware, the XMI interchange format is used for 
exchanging UML models between software tools.  However I have discovered that 
XMI does not support the transfer of graphical information.  

I have given this some thought and have decided to take a leaf out of ARGO's 
book and create multiple data files.  Now there will be a data file in XMI 
format that contains all the information that describes classes, 
associations, etc, plus a PGML file for every diagram in the model.  PGML 
format allows us to store graphical information that will allow us to 
reconstruct a KUML model from a file.

One drawback to this method is that there will be a large number of data 
files, any one of which could be missed when copying the model from one 
machine to another.  This of course will be a major problem, so after much 
thought I decided that a KUML model will be stored in a compressed TAR file.  
The TAR file will contain the XMI data file, a PGML file for every diagram, 
plus a manifest that describes what files make up the model.  At this stage I 
cannot see a better way, but once the initial IO subsystem is released I will 
be open to any suggestions.  I am concerned about the performance of this 
mechanism, but will have to get it working and then do some benchmarking.

On the KDE 2 front, I have been continuing to port KUML to KDE 2 and have a 
working copy.  There is still a lot of things to be completed, because at 
this stage I have done enough to allow me to create class diagrams.  As you 
have probably already seen, I have defined a constant KDE2 which determines 
that we are building under KDE 2.  I have wrapped all my KDE2 changes within 
#ifdef so that (hopefully) developers on KDE 1.X are not inconvenienced too 
much.  As far as I am aware I am the only person working on KDE 2, so if one 
of the other developers has trouble building on KDE 1, point him in my 
direction.

Regards...Geoff

-- 
Geoff Glasson
glastech@iinet.net.au
-------------------------------------------------------

-- 

Darius Stachow

[prev in list] [next in list] [prev in thread] [next in thread]