[openroad-developer] Empire XML Support - Two review meetingtimesscheduled on May 20th 2008

[Bodo Bergmann]

See comments below.

> _____________________________________________ 
> From: 	Sean Thrower  
> Sent:	Tuesday, May 20, 2008 1:48 PM
> To:	Bodo Bergmann
> Cc:	Joseph C. Kronk; Roger L. Whitcomb;
> openroad-developer at lists.ingres.com
> Subject:	RE: [openroad-developer] Empire XML Support - Two review
> meetingtimesscheduled on May 20th 2008
> 
> Bodo,
> 
> Comments on the export format below.
> 
> Regards,
> Sean.
> 
> 
> ... I still don't really get what -appsource is for:  if it is to
> profile the application, it doesn't tell you enough, since 
> *	the vnode::database out of context has no value
[Bodo] See my other mail for comment. 
> *	the trickiest part of application inclusion is the build
> sequence, which could be pre-generated (I and no doubt others have
> code for this) and stored in the export, but can't be generated from
> the export.
[Bodo]  Once the export file is in XML format, threre shouldn't be a
problem to parse it and generate the build sequence from it. 

> 3.3.1	
> - Classname values lowercase:
> *	This is inconsistent with our current systemclass standard (even
> if it is preferable:-))
[Bodo]  Why is it not consistent? If you create an attribute of a
UserClass to some system class it will be automatically converted to
lowercase.
         In addition it is a format which can be most easily be parsed
(performance).
	This has nothing to do with the names of an actual UserClasses -
these "classname" attributes are only for the purpose of export/import,
	e.g. for the component type.
> *	Can I suggest that we store classname and displayname, to avoid
> later anguish? (I realize that this would at the present moment be a
> duplication, though hardly a serious one).
[Bodo]  I think there is a misunderstanding. If you talk of a UserClass,
then this is a ClassSource, which has a name, which can be mixed case.
	This mixed case will be preserved, as the "name" will be written
as attribute of the SOURCEOBJECT with classname "classsource", e.g.:
	<SOURCEOBJECT classname="classsource" name="MyClass"> ...
> *	 Specifically I don't want to assume anything about future
> persistence of userclasses (which by OO convention have mixed-case
> naming), whether as 
> *	Customized data stores, eg. for Appserver
> 1	Customized definition stores, like queryobjects  
> 2	System-class extensions
> - Treating stringobjects and bitmapobjects as special cases.  Maybe
> I've misunderstood, but:
> *	What happens to filehandle and dbhandle?
[Bodo]  We still have to decide if these attributes are relevant - they
are definitly not required for restoring the value.
	They are just for the history of the object (where has it once
created from), but that file or db stored something might not even exist
when I import the export file.
> *	Extension of these classes surely becomes impossible?
> *	Suppose we were to introduce a persistent RW attribute at
> StringObject, BitmapObject, or even Object level, something that has
> been discussed in the past?  Or implement variant as a TypeObject from
> which all datatype objects inherited?
> *	 No problem for export of other classes, but no way of doing so
> for these, if I have understood correctly? 
			[Bodo]  Why should it be impossible? If you
extend the class then you extend the according methods that create the
XML for it or recreate its attributes from XML.
			I don't see your point?
> - Base64 encoding:
> *	I'm showing my ignorance here, but is this the best option in
> terms of text-based compression?
> *	(What is making me twitchy here is that yesterday I was testing
> fp_clear on my empire installation (I nearly got it to work) and used
> the nearest bitmap to hand, a 1.3MB jpeg.  Then I tried to save it -
> it had expanded to 50MB!)
	[Bodo]  BASE64 is the standard way of doing this - we also use
it when passing BitmapObjects to the OpenROAD Server.
	I know it's not ideal, but how about dynamically loading the
bitmaps from files or db at runtime - then you don't blow up the
FrameSource with it.

> 3.3.2
> - XML Schema:
> *	I'm uneasy about the very loose coupling implied here between
> the schema and the hardcoded load process.
> *	Is it possible to at least generate the schema from the internal
> definitions, so that there is some guarantee of consistency?
	[Bodo]  That's not so easy as there is no 1:1 relationship
between the internal implementation of attributes and the
documented/human-readable output.
	But we should investigate this.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ingres.com/pipermail/openroad-developer/attachments/20080520/6678003f/attachment.html