Berin:
I'm confussed - I don't understand what this would provide nor why you think its an important piece. Based on the current model you would use tools to generate a Type defintion - the tool maps between an input format and a Type. A Fortress tool could read in whatever and generate the Type directly. Code inside Fortress would then code against the meta-info API.
Fortress has more than one stream associated with the type information. Extensions will have their own file formats (the two I listed are examples). I believe it is important to have one set of tools for all containers. That is the purpose of separating out the Meta model and working on it in scratchpad.
Steve.
Berin Loritsch wrote:
One thing that seems to be missing from the meta-info SPI library is the separation from stream/persistence. The issue here is that some things are always tracked in separate files. Examples include JMX extensions, Configuration schemas, etc.
Instead of assuming one file contains all the meta info, we should allow the reader/writer to ask for a resource by changing the extension alone.
For example:
interface MetaInfoResource { InputStream getMetaInputStream( String extension ); OutputStream getMetaOutputStream( String extension ); }
The Readers and Writers will be able to get all the different streams that belong to the particular resource. It will also allow extensions to load their specific information as necessary.
I believe this is very important piece of the system we need. It will also help me write the readers/writers for existing Fortress components.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
