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

[Sean Thrower]

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 
-	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.

3.3.1	
- Classname values lowercase:
-	This is inconsistent with our current systemclass standard (even
if it is preferable:-))
-	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). Specifically I don't want to
assume anything about future persistence of userclasses (which by OO
convention have mixed-case naming), whether as 
o	Customized data stores, eg. for Appserver
o	Customized definition stores, like queryobjects  
o	System-class extensions
- Treating stringobjects and bitmapobjects as special cases.  Maybe I've
misunderstood, but:
-	What happens to filehandle and dbhandle?
-	Extension of these classes surely becomes impossible?
o	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? 
- Base64 encoding:
-	I'm showing my ignorance here, but is this the best option in
terms of text-based compression?
o	(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!)

3.3.2
- XML Schema:
-	I'm uneasy about the very loose coupling implied here between
the schema and the hardcoded load process.
o	Is it possible to at least generate the schema from the internal
definitions, so that there is some guarantee of consistency?

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