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

List:       kde-kuml-devel
Subject:    
From:       glastech () iinet ! net ! au
Date:       2000-06-26 12:50:15
[Download RAW message or body]

	([127.0.0.1] helo=delenn.glastech.com.au ident=gjg)
	by delenn.glastech.com.au with smtp (Exim 3.14 #2)
	id 136jPk-0000KP-00
	for kuml-devel@barney.cs.uni-potsdam.de; Mon, 26 Jun 2000 20:39:44 -0400
From: Geoff Glasson <gjg@delenn.glastech.com.au>
Reply-To: Geoff Glasson<glastech@iinet.net.au>
To: kuml-devel@barney.cs.uni-potsdam.de
Subject: Fwd: Re: IO subsystem
Date: Mon, 26 Jun 2000 20:39:44 -0400
X-Mailer: KMail [version 1.1.50]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <00062620394400.01236@delenn.glastech.com.au>
Content-Transfer-Encoding: 8bit
return-path: glastech@iinet.net.au

Hi guys,

I've been keeping Darius up to date with what I've been doing and he 
suggested that I post to this group.  So this is the e-mail that I sent him.

I have been using KDE 2.0 (Kleopatra) on Linux and have just installed 
FreeBSD and KDE 1.1.2 running under VMWare.  I am attempting to ensure that 
everything I do builds on both (unlike in the past).

Geoff

----------  Forwarded Message  ----------
Subject: Re: IO subsystem
Date: Tue, 13 Jun 2000 19:54:00 -0400
From: Geoff Glasson <gjg>
To: Darius Stachow <dstachow@ngi.de>


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

-------------------------------------------------------

-- 
Geoff Glasson
glastech@iinet.net.au

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