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.
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.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
