Menu
▾
▴
[Corelinux-clcvs] CVS: htdocs/develop/develop develop.html,1.9,1.10 index.html,1.9,1.10
|
From: Frank V. C. <fr...@us...> - 2001-04-29 10:45:45
|
Update of /cvsroot/corelinux/htdocs/develop/develop
In directory usw-pr-cvs1:/tmp/cvs-serv21759/develop
Modified Files:
develop.html index.html
Log Message:
Schema Update
Index: develop.html
===================================================================
RCS file: /cvsroot/corelinux/htdocs/develop/develop/develop.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -r1.9 -r1.10
*** develop.html 2000/10/07 17:16:57 1.9
--- develop.html 2001/04/29 10:45:41 1.10
***************
*** 27,31 ****
<H1 ALIGN="CENTER">CoreLinux++ Development</H1>
<P ALIGN="CENTER"><STRONG>The Corelinux Consortium</STRONG></P>
! <P ALIGN="CENTER"><STRONG>Revision: 1.9 </STRONG></P>
<P>
--- 27,31 ----
<H1 ALIGN="CENTER">CoreLinux++ Development</H1>
<P ALIGN="CENTER"><STRONG>The Corelinux Consortium</STRONG></P>
! <P ALIGN="CENTER"><STRONG>Revision: 1.10 </STRONG></P>
<P>
***************
*** 46,137 ****
<UL>
! <LI><A NAME="tex2html47"
HREF="develop.php">Introduction</A>
! <LI><A NAME="tex2html48"
HREF="develop.php#SECTION00020000000000000000">Setting Up for CoreLinux++ builds</A>
<UL>
! <LI><A NAME="tex2html49"
HREF="develop.php#SECTION00021000000000000000">Getting Things Rolling</A>
! <LI><A NAME="tex2html50"
HREF="develop.php#SECTION00022000000000000000">Make Environment</A>
! <LI><A NAME="tex2html51"
HREF="develop.php#SECTION00023000000000000000">Setting up for CoreLinux++ Execution</A>
! <LI><A NAME="tex2html52"
HREF="develop.php#SECTION00024000000000000000">Directory Structure</A>
<UL>
! <LI><A NAME="tex2html53"
HREF="develop.php#SECTION00024100000000000000">The Root Directory</A>
! <LI><A NAME="tex2html54"
HREF="develop.php#SECTION00024200000000000000">The Root Include</A>
! <LI><A NAME="tex2html55"
HREF="develop.php#SECTION00024300000000000000">The Root Source Root</A>
! <LI><A NAME="tex2html56"
HREF="develop.php#SECTION00024400000000000000">Class Library Source Root</A>
! <LI><A NAME="tex2html57"
HREF="develop.php#SECTION00024500000000000000">CoreLinux Class Library Source</A>
! <LI><A NAME="tex2html58"
HREF="develop.php#SECTION00024600000000000000">Additional Class Library Source</A>
! <LI><A NAME="tex2html59"
HREF="develop.php#SECTION00024700000000000000">The Test Driver and Example Code Root</A>
! <LI><A NAME="tex2html60"
HREF="develop.php#SECTION00024800000000000000">Example application source</A>
! <LI><A NAME="tex2html61"
HREF="develop.php#SECTION00024900000000000000">CoreLinux++ Documentation for Standards, Class Reference, Requirements, Analysis, and Design</A>
</UL>
</UL>
! <LI><A NAME="tex2html62"
HREF="develop.php#SECTION00030000000000000000">Standard Development Process</A>
! <LI><A NAME="tex2html63"
HREF="develop.php#SECTION00040000000000000000">Developing with CoreLinux++</A>
<UL>
! <LI><A NAME="tex2html64"
HREF="develop.php#SECTION00041000000000000000">Using autoconf</A>
! <LI><A NAME="tex2html65"
HREF="develop.php#SECTION00042000000000000000">Macros</A>
</UL>
! <LI><A NAME="tex2html66"
HREF="develop.php#SECTION00050000000000000000">Class Library Internals</A>
<UL>
! <LI><A NAME="tex2html67"
HREF="develop.php#SECTION00051000000000000000">Foundation Classes</A>
! <LI><A NAME="tex2html68"
HREF="develop.php#SECTION00052000000000000000">Inter-Process Communication</A>
<UL>
! <LI><A NAME="tex2html69"
HREF="develop.php#SECTION00052100000000000000">Semaphore and SemaphoreGroup</A>
! <LI><A NAME="tex2html70"
HREF="develop.php#SECTION00052200000000000000">Threads</A>
</UL>
! <LI><A NAME="tex2html71"
HREF="develop.php#SECTION00053000000000000000">Design Patterns</A>
</UL>
! <LI><A NAME="tex2html72"
HREF="develop.php#SECTION00060000000000000000">Frameworks</A>
<UL>
! <LI><A NAME="tex2html73"
HREF="develop.php#SECTION00061000000000000000">Framework Support</A>
! <LI><A NAME="tex2html74"
HREF="develop.php#SECTION00062000000000000000">Meta-class MetaType</A>
! <LI><A NAME="tex2html75"
HREF="develop.php#SECTION00063000000000000000">MetaType Macros</A>
! <LI><A NAME="tex2html76"
HREF="develop.php#SECTION00064000000000000000">Ontology</A>
! <LI><A NAME="tex2html77"
HREF="develop.php#SECTION00065000000000000000">MetaType Ontology</A>
! <LI><A NAME="tex2html78"
HREF="develop.php#SECTION00066000000000000000">Common franework abstractions</A>
<UL>
! <LI><A NAME="tex2html79"
HREF="develop.php#SECTION00066100000000000000">Library Load</A>
</UL>
! <LI><A NAME="tex2html80"
! HREF="develop.php#SECTION00067000000000000000">Persistence</A>
</UL>
! <LI><A NAME="tex2html81"
HREF="develop.php#SECTION00070000000000000000">Bibliography</A>
</UL>
<!--End of Table of Contents-->
! <P><b>Copyright notice</b><br><br><tt>CoreLinux++ Copyright (c) 1999, 2000 CoreLinux Consortium</tt><br><tt><TT>Revision 1.9 </TT>, Last Modified:
! 2000/09/05</tt><br>This material may be distributed only subject to the terms and conditions set forth in the Open Publication License.<p>
<P>
--- 46,149 ----
<UL>
! <LI><A NAME="tex2html52"
HREF="develop.php">Introduction</A>
! <LI><A NAME="tex2html53"
HREF="develop.php#SECTION00020000000000000000">Setting Up for CoreLinux++ builds</A>
<UL>
! <LI><A NAME="tex2html54"
HREF="develop.php#SECTION00021000000000000000">Getting Things Rolling</A>
! <LI><A NAME="tex2html55"
HREF="develop.php#SECTION00022000000000000000">Make Environment</A>
! <LI><A NAME="tex2html56"
HREF="develop.php#SECTION00023000000000000000">Setting up for CoreLinux++ Execution</A>
! <LI><A NAME="tex2html57"
HREF="develop.php#SECTION00024000000000000000">Directory Structure</A>
<UL>
! <LI><A NAME="tex2html58"
HREF="develop.php#SECTION00024100000000000000">The Root Directory</A>
! <LI><A NAME="tex2html59"
HREF="develop.php#SECTION00024200000000000000">The Root Include</A>
! <LI><A NAME="tex2html60"
HREF="develop.php#SECTION00024300000000000000">The Root Source Root</A>
! <LI><A NAME="tex2html61"
HREF="develop.php#SECTION00024400000000000000">Class Library Source Root</A>
! <LI><A NAME="tex2html62"
HREF="develop.php#SECTION00024500000000000000">CoreLinux Class Library Source</A>
! <LI><A NAME="tex2html63"
HREF="develop.php#SECTION00024600000000000000">Additional Class Library Source</A>
! <LI><A NAME="tex2html64"
HREF="develop.php#SECTION00024700000000000000">The Test Driver and Example Code Root</A>
! <LI><A NAME="tex2html65"
HREF="develop.php#SECTION00024800000000000000">Example application source</A>
! <LI><A NAME="tex2html66"
HREF="develop.php#SECTION00024900000000000000">CoreLinux++ Documentation for Standards, Class Reference, Requirements, Analysis, and Design</A>
</UL>
</UL>
! <LI><A NAME="tex2html67"
HREF="develop.php#SECTION00030000000000000000">Standard Development Process</A>
! <LI><A NAME="tex2html68"
HREF="develop.php#SECTION00040000000000000000">Developing with CoreLinux++</A>
<UL>
! <LI><A NAME="tex2html69"
HREF="develop.php#SECTION00041000000000000000">Using autoconf</A>
! <LI><A NAME="tex2html70"
HREF="develop.php#SECTION00042000000000000000">Macros</A>
</UL>
! <LI><A NAME="tex2html71"
HREF="develop.php#SECTION00050000000000000000">Class Library Internals</A>
<UL>
! <LI><A NAME="tex2html72"
HREF="develop.php#SECTION00051000000000000000">Foundation Classes</A>
! <LI><A NAME="tex2html73"
HREF="develop.php#SECTION00052000000000000000">Inter-Process Communication</A>
<UL>
! <LI><A NAME="tex2html74"
HREF="develop.php#SECTION00052100000000000000">Semaphore and SemaphoreGroup</A>
! <LI><A NAME="tex2html75"
HREF="develop.php#SECTION00052200000000000000">Threads</A>
</UL>
! <LI><A NAME="tex2html76"
HREF="develop.php#SECTION00053000000000000000">Design Patterns</A>
</UL>
! <LI><A NAME="tex2html77"
HREF="develop.php#SECTION00060000000000000000">Frameworks</A>
<UL>
! <LI><A NAME="tex2html78"
HREF="develop.php#SECTION00061000000000000000">Framework Support</A>
! <LI><A NAME="tex2html79"
HREF="develop.php#SECTION00062000000000000000">Meta-class MetaType</A>
! <LI><A NAME="tex2html80"
HREF="develop.php#SECTION00063000000000000000">MetaType Macros</A>
! <LI><A NAME="tex2html81"
HREF="develop.php#SECTION00064000000000000000">Ontology</A>
! <LI><A NAME="tex2html82"
HREF="develop.php#SECTION00065000000000000000">MetaType Ontology</A>
! <LI><A NAME="tex2html83"
HREF="develop.php#SECTION00066000000000000000">Common franework abstractions</A>
<UL>
! <LI><A NAME="tex2html84"
HREF="develop.php#SECTION00066100000000000000">Library Load</A>
</UL>
! <LI><A NAME="tex2html85"
! HREF="develop.php#SECTION00067000000000000000">Schemas And Persistence</A>
! <UL>
! <LI><A NAME="tex2html86"
! HREF="develop.php#SECTION00067100000000000000">Premise</A>
! <LI><A NAME="tex2html87"
! HREF="develop.php#SECTION00067200000000000000">Overview</A>
! <LI><A NAME="tex2html88"
! HREF="develop.php#SECTION00067300000000000000">Schema Modeling</A>
! <LI><A NAME="tex2html89"
! HREF="develop.php#SECTION00067400000000000000">Schema Run Time</A>
! <LI><A NAME="tex2html90"
! HREF="develop.php#SECTION00067500000000000000">Current Restrictions</A>
</UL>
! </UL>
! <LI><A NAME="tex2html91"
HREF="develop.php#SECTION00070000000000000000">Bibliography</A>
</UL>
<!--End of Table of Contents-->
! <P><b>Copyright notice</b><br><br><tt>CoreLinux++ Copyright (c) 1999, 2000 CoreLinux Consortium</tt><br><tt><TT>Revision 1.10 </TT>, Last Modified:
! 2000/10/07</tt><br>This material may be distributed only subject to the terms and conditions set forth in the Open Publication License.<p>
<P>
***************
*** 841,850 ****
<H2><A NAME="SECTION00067000000000000000"></A>
! <A NAME="sec:Persist"></A><BR>
! Persistence
</H2>
<P>
! There are many C++ applications that require the object instances to be saved and loaded for use across application or machine sessions.
<P>
--- 853,1069 ----
<H2><A NAME="SECTION00067000000000000000"></A>
! <A NAME="sec:SchmPersist"></A><BR>
! Schemas And Persistence
</H2>
+ <P>
+
+ <H3><A NAME="SECTION00067100000000000000"></A>
+ <A NAME="sec:SchmPersistPrem"></A><BR>
+ Premise
+ </H3>
+
+ <P>
+ The persistence abstraction is built on the premise that the actual storage service code, that which implements concrete persist services beneath the abstraction, should be intelligent enough to take guidance from domain descriptions (concepts). Said concepts define the types to be stored, in addition to other information, and it is the job of the storage service to manage the data layout and service execution as defined by it's implementation.
+
+ <P>
+ It is, after all, the 21st century.
+
+ <P>
+ This benefits the application developer from having to worry about the details of a particular storage service, as well as having the flexibility to change persist implementations at will, or by user choice.
+
+ <H3><A NAME="SECTION00067200000000000000"></A>
+ <A NAME="sec:SchmPersistOvr"></A><BR>
+ Overview
+ </H3>
+
+ <P>
+ There are actually two (2) aspects to the CoreLinux++ Abstract Persist framework: Schemas and Services. This release focuses on the newly provided Schema constructs. * Please refer to the current implementation restrictions at the end of this document.
+
+ <P>
+ A Schema is an organization of concepts to model an idea. In this case, what is being modeled are the types that the application will want to have made persistent. When a schema has been modeled, it is then usable as a roadmap, in effect, to guide the storage implementation. For example, the types may represent tables in a relational database storage service, or a file type for a flat file service. It is ultimatley up to the service to decide how to "plan the trip".
+
+ <P>
+ There are two (2) workflows around Schemas and their concepts: Model and Run. Lets talk turkey first:
+
+ <P>
+
+ <H3><A NAME="SECTION00067300000000000000"></A>
+ <A NAME="sec:SchmPersistMod"></A><BR>
+ Schema Modeling
+ </H3>
+
+ <P>
+ Schema modeling is supported through built-in services and functions of the library. All modeling changes are persisted to gdbm databases, and the domain modeler need only focus on making their schema correct. While there is a tremendous opportunity for adventerous open source developers to build tools around this (GUI, etc.), the library contains the fundemental capabilities to Create, Request, Update, and Delete Schemas or their artifacts (concepts).
+
+ <P>
+ The example test driver (clfw/src/testdrivers/exf2) shows some of the following capabilities.
+
+ <P>
+ 1. Typically, start by resolving the SchemaSponsor and creating an
+ instance of it.
+
+ <P>
+ 2. From the Sponser, get the Catalog object instance.
+
+ <P>
+ 3. Create, Edit, Save, Close, Delete Schemas using the interface
+ of the Catalog instance.
+
+ <P>
+ 4. Create Concepts and add to Schema
+
+ <P>
+ 5. Remove Concepts from Schema and delete
+
+ <P>
+
+ <H3><A NAME="SECTION00067400000000000000"></A>
+ <A NAME="sec:SchmPersistRun"></A><BR>
+ Schema Run Time
+ </H3>
+
+ <P>
+ Once a Schema has been modeled, it can be used by a storage service to support the input and output operations of application objects.
+
+ <P>
+ 1. Like Schema modeling, the activation of persistence in an application starts with the resolving and instance creation of a StoreSponser. This can be done be either using the the StoreSponser class name and resolving through the Ontology interfaces.
+
+ <P>
+ For example:
+
+ <P>
+ StoreSponsorPtr aSponsor
+ (
+ StoreSponsor::castDown(getInstanceOf("MySQLSponsor"))
+ );
+
+ <P>
+ or by walking the StoreSponser MetaClass hierarchy and testing each of the children nodes until you find the one you want. In latter releases we will have support for descriptive attributes on MetaClasses to help reason with sponser types and capabilities.
+
+ <P>
+ Another way to load a Sponser would be to work in conjunction with plug-in support to dynamically load types that are not part of the library compilation. Sounds like a job for the CoreLinux++ Library Load
+ capability!
+
+ <P>
+ Note: In the above code example it presumes that someone has provided a MySQL persistence implementation.
+
+ <P>
+ 2. From the Sponser, get the Catalog object instance.
+
+ <P>
+ 3. Create a Store (which would require identifying the Schema to be used
+ as the roadmap).
+
+ <P>
+ 4. Fetch a Store to write and read application object instances from and
+ to respectivley.
+
+ <P>
+
+ <H3><A NAME="SECTION00067500000000000000"></A>
+ <A NAME="sec:SchmPersistRest"></A><BR>
+ Current Restrictions
+ </H3>
+
+ <P>
+ Name/Value Declarations
+
+ <P>
+ While ultimately Schemas and Concepts attributes won't be limited as to the
+ depth or types supported, the current implementation assumes most attributes
+ are of the form: Name:Value, where:
+
+ <P>
+ Name is the Key data member of the Attribute and should be of type
+ FrameworkString
+
+ <P>
+ Value is the Value data member of the Attribute and should be of type
+ FrameworkString
+
+ <P>
+ Primary Schema Declarations
+
+ <P>
+ For schemas, the following are the recognized attribute keys:
+ <PRE>
+ Attribute Key : "Name"
+ Expected Value : Unique name for this schema
+ Example : "Franks Schema"
+ Note : This is a required attribute
+
+ Attribute Key : "Collection"
+ Expected Value : The collection type literal (currently "Array" or "SetCollection")
+ Note : SetCollection is safer for insuring unique name keys, although as new collection types are added it is really up to the modeling support.
+ Note : This is a required attribute
+
+ Attribute Key : "Location"
+ Expected Value : Qualified path where schema should be stored
+ Note : This is an optional attribute, default is ~/.clfw++/schemas/"Name"
+
+ Attribute Key : "GUID"
+ Expected Value : Stringified UniversalIdentifier to be used
+ Note : This is an optional attribute, default is the system will generate.
+ </PRE>
+
+ <P>
+ with the following attribute expected to be supported in later releases:
+
+ <P>
+ <PRE>
+ Attribute Key : "SchemaClass"
+ Expected Value : The Schema class type literal to be used when instantiating a new schema, this will be stored with the Schema descriptor and will be used when reloading in new sessions.
+ Example : "FranksWickedSchemaDerivation"
+ </PRE>
+
+ <P>
+ Primary Concept Declarations
+ <PRE>
+ Attribute Key : "Name"
+ Expected Value : Unique name for this schema
+ Example : "Concept A1"
+ Note : Even though concepts can be created for other reasons, this is a required attribute if adding to a Schema
+
+ Attribute Key : "Class"
+ Expected Value : Stringified UniversalIdentifier of the type that this Concept defines representation of to the storage service.
+ Note : Even though concepts can be created for other reasons, this is a required attribute if adding to a Schema
+ </PRE>
+
+ <P>
+ with the following attributes expected to be supported in later releases:
+ <PRE>
+ Attribute Key : "Uses"
+ Expected Value : Collection type, where the collection contains attributes that describe data types of this object should reuse the storage managed by another concepts definition, therefore the nested attributes are:
+ Attribute Key : "Data Member Name"
+ Expected Value : "Concept Name"
+
+ where:
+
+ "Data Member Name" is the name of the data member that has been
+ explicitly identified in the MetaClass definition of the entity
+ being stored.
+
+ "Concept Name" is the name of another concept in the Schema
+ (which one would have to presume is the same type of the Data
+ Member).
+
+ Attribute Key : "Ignore"
+ Expected Value : Collection type, where the collection contains
+ single string values that identify (by name) the Data Members of
+ the Class that the storage management should ignore. In
+ otherword don't write or expect to read from persist.
+
+ Attribute Key : "Fence"
+ Expected Value : Collection type, where the collection contains
+ single string values that identify (by name) the Data Members of
+ the Class that the storage manager should recognize as an indicator
+ that the application whats instances of this data member to be handled
+ as a separate table/file/etc. according to it's (storage service)
+ domain.
+ </PRE>
+
<P>
! Please note that these would be considered "suggestions" that the declaration of which does not imply that a storage service would do anything with the information.
<P>
***************
*** 885,889 ****
<ADDRESS>
Frank V. Castellucci
! 2000-10-07
</ADDRESS>
</BODY>
--- 1104,1108 ----
<ADDRESS>
Frank V. Castellucci
! 2001-04-29
</ADDRESS>
</BODY>
Index: index.html
===================================================================
RCS file: /cvsroot/corelinux/htdocs/develop/develop/index.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -r1.9 -r1.10
*** index.html 2000/10/07 17:16:57 1.9
--- index.html 2001/04/29 10:45:41 1.10
***************
*** 27,31 ****
<H1 ALIGN="CENTER">CoreLinux++ Development</H1>
<P ALIGN="CENTER"><STRONG>The Corelinux Consortium</STRONG></P>
! <P ALIGN="CENTER"><STRONG>Revision: 1.9 </STRONG></P>
<P>
--- 27,31 ----
<H1 ALIGN="CENTER">CoreLinux++ Development</H1>
<P ALIGN="CENTER"><STRONG>The Corelinux Consortium</STRONG></P>
! <P ALIGN="CENTER"><STRONG>Revision: 1.10 </STRONG></P>
<P>
***************
*** 46,137 ****
<UL>
! <LI><A NAME="tex2html47"
HREF="develop.html">Introduction</A>
! <LI><A NAME="tex2html48"
HREF="develop.html#SECTION00020000000000000000">Setting Up for CoreLinux++ builds</A>
<UL>
! <LI><A NAME="tex2html49"
HREF="develop.html#SECTION00021000000000000000">Getting Things Rolling</A>
! <LI><A NAME="tex2html50"
HREF="develop.html#SECTION00022000000000000000">Make Environment</A>
! <LI><A NAME="tex2html51"
HREF="develop.html#SECTION00023000000000000000">Setting up for CoreLinux++ Execution</A>
! <LI><A NAME="tex2html52"
HREF="develop.html#SECTION00024000000000000000">Directory Structure</A>
<UL>
! <LI><A NAME="tex2html53"
HREF="develop.html#SECTION00024100000000000000">The Root Directory</A>
! <LI><A NAME="tex2html54"
HREF="develop.html#SECTION00024200000000000000">The Root Include</A>
! <LI><A NAME="tex2html55"
HREF="develop.html#SECTION00024300000000000000">The Root Source Root</A>
! <LI><A NAME="tex2html56"
HREF="develop.html#SECTION00024400000000000000">Class Library Source Root</A>
! <LI><A NAME="tex2html57"
HREF="develop.html#SECTION00024500000000000000">CoreLinux Class Library Source</A>
! <LI><A NAME="tex2html58"
HREF="develop.html#SECTION00024600000000000000">Additional Class Library Source</A>
! <LI><A NAME="tex2html59"
HREF="develop.html#SECTION00024700000000000000">The Test Driver and Example Code Root</A>
! <LI><A NAME="tex2html60"
HREF="develop.html#SECTION00024800000000000000">Example application source</A>
! <LI><A NAME="tex2html61"
HREF="develop.html#SECTION00024900000000000000">CoreLinux++ Documentation for Standards, Class Reference, Requirements, Analysis, and Design</A>
</UL>
</UL>
! <LI><A NAME="tex2html62"
HREF="develop.html#SECTION00030000000000000000">Standard Development Process</A>
! <LI><A NAME="tex2html63"
HREF="develop.html#SECTION00040000000000000000">Developing with CoreLinux++</A>
<UL>
! <LI><A NAME="tex2html64"
HREF="develop.html#SECTION00041000000000000000">Using autoconf</A>
! <LI><A NAME="tex2html65"
HREF="develop.html#SECTION00042000000000000000">Macros</A>
</UL>
! <LI><A NAME="tex2html66"
HREF="develop.html#SECTION00050000000000000000">Class Library Internals</A>
<UL>
! <LI><A NAME="tex2html67"
HREF="develop.html#SECTION00051000000000000000">Foundation Classes</A>
! <LI><A NAME="tex2html68"
HREF="develop.html#SECTION00052000000000000000">Inter-Process Communication</A>
<UL>
! <LI><A NAME="tex2html69"
HREF="develop.html#SECTION00052100000000000000">Semaphore and SemaphoreGroup</A>
! <LI><A NAME="tex2html70"
HREF="develop.html#SECTION00052200000000000000">Threads</A>
</UL>
! <LI><A NAME="tex2html71"
HREF="develop.html#SECTION00053000000000000000">Design Patterns</A>
</UL>
! <LI><A NAME="tex2html72"
HREF="develop.html#SECTION00060000000000000000">Frameworks</A>
<UL>
! <LI><A NAME="tex2html73"
HREF="develop.html#SECTION00061000000000000000">Framework Support</A>
! <LI><A NAME="tex2html74"
HREF="develop.html#SECTION00062000000000000000">Meta-class MetaType</A>
! <LI><A NAME="tex2html75"
HREF="develop.html#SECTION00063000000000000000">MetaType Macros</A>
! <LI><A NAME="tex2html76"
HREF="develop.html#SECTION00064000000000000000">Ontology</A>
! <LI><A NAME="tex2html77"
HREF="develop.html#SECTION00065000000000000000">MetaType Ontology</A>
! <LI><A NAME="tex2html78"
HREF="develop.html#SECTION00066000000000000000">Common franework abstractions</A>
<UL>
! <LI><A NAME="tex2html79"
HREF="develop.html#SECTION00066100000000000000">Library Load</A>
</UL>
! <LI><A NAME="tex2html80"
! HREF="develop.html#SECTION00067000000000000000">Persistence</A>
</UL>
! <LI><A NAME="tex2html81"
HREF="develop.html#SECTION00070000000000000000">Bibliography</A>
</UL>
<!--End of Table of Contents-->
! <P><b>Copyright notice</b><br><br><tt>CoreLinux++ Copyright (c) 1999, 2000 CoreLinux Consortium</tt><br><tt><TT>Revision 1.9 </TT>, Last Modified:
! 2000/09/05</tt><br>This material may be distributed only subject to the terms and conditions set forth in the Open Publication License.<p>
<P>
--- 46,149 ----
<UL>
! <LI><A NAME="tex2html52"
HREF="develop.html">Introduction</A>
! <LI><A NAME="tex2html53"
HREF="develop.html#SECTION00020000000000000000">Setting Up for CoreLinux++ builds</A>
<UL>
! <LI><A NAME="tex2html54"
HREF="develop.html#SECTION00021000000000000000">Getting Things Rolling</A>
! <LI><A NAME="tex2html55"
HREF="develop.html#SECTION00022000000000000000">Make Environment</A>
! <LI><A NAME="tex2html56"
HREF="develop.html#SECTION00023000000000000000">Setting up for CoreLinux++ Execution</A>
! <LI><A NAME="tex2html57"
HREF="develop.html#SECTION00024000000000000000">Directory Structure</A>
<UL>
! <LI><A NAME="tex2html58"
HREF="develop.html#SECTION00024100000000000000">The Root Directory</A>
! <LI><A NAME="tex2html59"
HREF="develop.html#SECTION00024200000000000000">The Root Include</A>
! <LI><A NAME="tex2html60"
HREF="develop.html#SECTION00024300000000000000">The Root Source Root</A>
! <LI><A NAME="tex2html61"
HREF="develop.html#SECTION00024400000000000000">Class Library Source Root</A>
! <LI><A NAME="tex2html62"
HREF="develop.html#SECTION00024500000000000000">CoreLinux Class Library Source</A>
! <LI><A NAME="tex2html63"
HREF="develop.html#SECTION00024600000000000000">Additional Class Library Source</A>
! <LI><A NAME="tex2html64"
HREF="develop.html#SECTION00024700000000000000">The Test Driver and Example Code Root</A>
! <LI><A NAME="tex2html65"
HREF="develop.html#SECTION00024800000000000000">Example application source</A>
! <LI><A NAME="tex2html66"
HREF="develop.html#SECTION00024900000000000000">CoreLinux++ Documentation for Standards, Class Reference, Requirements, Analysis, and Design</A>
</UL>
</UL>
! <LI><A NAME="tex2html67"
HREF="develop.html#SECTION00030000000000000000">Standard Development Process</A>
! <LI><A NAME="tex2html68"
HREF="develop.html#SECTION00040000000000000000">Developing with CoreLinux++</A>
<UL>
! <LI><A NAME="tex2html69"
HREF="develop.html#SECTION00041000000000000000">Using autoconf</A>
! <LI><A NAME="tex2html70"
HREF="develop.html#SECTION00042000000000000000">Macros</A>
</UL>
! <LI><A NAME="tex2html71"
HREF="develop.html#SECTION00050000000000000000">Class Library Internals</A>
<UL>
! <LI><A NAME="tex2html72"
HREF="develop.html#SECTION00051000000000000000">Foundation Classes</A>
! <LI><A NAME="tex2html73"
HREF="develop.html#SECTION00052000000000000000">Inter-Process Communication</A>
<UL>
! <LI><A NAME="tex2html74"
HREF="develop.html#SECTION00052100000000000000">Semaphore and SemaphoreGroup</A>
! <LI><A NAME="tex2html75"
HREF="develop.html#SECTION00052200000000000000">Threads</A>
</UL>
! <LI><A NAME="tex2html76"
HREF="develop.html#SECTION00053000000000000000">Design Patterns</A>
</UL>
! <LI><A NAME="tex2html77"
HREF="develop.html#SECTION00060000000000000000">Frameworks</A>
<UL>
! <LI><A NAME="tex2html78"
HREF="develop.html#SECTION00061000000000000000">Framework Support</A>
! <LI><A NAME="tex2html79"
HREF="develop.html#SECTION00062000000000000000">Meta-class MetaType</A>
! <LI><A NAME="tex2html80"
HREF="develop.html#SECTION00063000000000000000">MetaType Macros</A>
! <LI><A NAME="tex2html81"
HREF="develop.html#SECTION00064000000000000000">Ontology</A>
! <LI><A NAME="tex2html82"
HREF="develop.html#SECTION00065000000000000000">MetaType Ontology</A>
! <LI><A NAME="tex2html83"
HREF="develop.html#SECTION00066000000000000000">Common franework abstractions</A>
<UL>
! <LI><A NAME="tex2html84"
HREF="develop.html#SECTION00066100000000000000">Library Load</A>
</UL>
! <LI><A NAME="tex2html85"
! HREF="develop.html#SECTION00067000000000000000">Schemas And Persistence</A>
! <UL>
! <LI><A NAME="tex2html86"
! HREF="develop.html#SECTION00067100000000000000">Premise</A>
! <LI><A NAME="tex2html87"
! HREF="develop.html#SECTION00067200000000000000">Overview</A>
! <LI><A NAME="tex2html88"
! HREF="develop.html#SECTION00067300000000000000">Schema Modeling</A>
! <LI><A NAME="tex2html89"
! HREF="develop.html#SECTION00067400000000000000">Schema Run Time</A>
! <LI><A NAME="tex2html90"
! HREF="develop.html#SECTION00067500000000000000">Current Restrictions</A>
</UL>
! </UL>
! <LI><A NAME="tex2html91"
HREF="develop.html#SECTION00070000000000000000">Bibliography</A>
</UL>
<!--End of Table of Contents-->
! <P><b>Copyright notice</b><br><br><tt>CoreLinux++ Copyright (c) 1999, 2000 CoreLinux Consortium</tt><br><tt><TT>Revision 1.10 </TT>, Last Modified:
! 2000/10/07</tt><br>This material may be distributed only subject to the terms and conditions set forth in the Open Publication License.<p>
<P>
***************
*** 841,850 ****
<H2><A NAME="SECTION00067000000000000000"></A>
! <A NAME="sec:Persist"></A><BR>
! Persistence
</H2>
<P>
! There are many C++ applications that require the object instances to be saved and loaded for use across application or machine sessions.
<P>
--- 853,1069 ----
<H2><A NAME="SECTION00067000000000000000"></A>
! <A NAME="sec:SchmPersist"></A><BR>
! Schemas And Persistence
</H2>
+ <P>
+
+ <H3><A NAME="SECTION00067100000000000000"></A>
+ <A NAME="sec:SchmPersistPrem"></A><BR>
+ Premise
+ </H3>
+
+ <P>
+ The persistence abstraction is built on the premise that the actual storage service code, that which implements concrete persist services beneath the abstraction, should be intelligent enough to take guidance from domain descriptions (concepts). Said concepts define the types to be stored, in addition to other information, and it is the job of the storage service to manage the data layout and service execution as defined by it's implementation.
+
+ <P>
+ It is, after all, the 21st century.
+
+ <P>
+ This benefits the application developer from having to worry about the details of a particular storage service, as well as having the flexibility to change persist implementations at will, or by user choice.
+
+ <H3><A NAME="SECTION00067200000000000000"></A>
+ <A NAME="sec:SchmPersistOvr"></A><BR>
+ Overview
+ </H3>
+
+ <P>
+ There are actually two (2) aspects to the CoreLinux++ Abstract Persist framework: Schemas and Services. This release focuses on the newly provided Schema constructs. * Please refer to the current implementation restrictions at the end of this document.
+
+ <P>
+ A Schema is an organization of concepts to model an idea. In this case, what is being modeled are the types that the application will want to have made persistent. When a schema has been modeled, it is then usable as a roadmap, in effect, to guide the storage implementation. For example, the types may represent tables in a relational database storage service, or a file type for a flat file service. It is ultimatley up to the service to decide how to "plan the trip".
+
+ <P>
+ There are two (2) workflows around Schemas and their concepts: Model and Run. Lets talk turkey first:
+
+ <P>
+
+ <H3><A NAME="SECTION00067300000000000000"></A>
+ <A NAME="sec:SchmPersistMod"></A><BR>
+ Schema Modeling
+ </H3>
+
+ <P>
+ Schema modeling is supported through built-in services and functions of the library. All modeling changes are persisted to gdbm databases, and the domain modeler need only focus on making their schema correct. While there is a tremendous opportunity for adventerous open source developers to build tools around this (GUI, etc.), the library contains the fundemental capabilities to Create, Request, Update, and Delete Schemas or their artifacts (concepts).
+
+ <P>
+ The example test driver (clfw/src/testdrivers/exf2) shows some of the following capabilities.
+
+ <P>
+ 1. Typically, start by resolving the SchemaSponsor and creating an
+ instance of it.
+
+ <P>
+ 2. From the Sponser, get the Catalog object instance.
+
+ <P>
+ 3. Create, Edit, Save, Close, Delete Schemas using the interface
+ of the Catalog instance.
+
+ <P>
+ 4. Create Concepts and add to Schema
+
+ <P>
+ 5. Remove Concepts from Schema and delete
+
+ <P>
+
+ <H3><A NAME="SECTION00067400000000000000"></A>
+ <A NAME="sec:SchmPersistRun"></A><BR>
+ Schema Run Time
+ </H3>
+
+ <P>
+ Once a Schema has been modeled, it can be used by a storage service to support the input and output operations of application objects.
+
+ <P>
+ 1. Like Schema modeling, the activation of persistence in an application starts with the resolving and instance creation of a StoreSponser. This can be done be either using the the StoreSponser class name and resolving through the Ontology interfaces.
+
+ <P>
+ For example:
+
+ <P>
+ StoreSponsorPtr aSponsor
+ (
+ StoreSponsor::castDown(getInstanceOf("MySQLSponsor"))
+ );
+
+ <P>
+ or by walking the StoreSponser MetaClass hierarchy and testing each of the children nodes until you find the one you want. In latter releases we will have support for descriptive attributes on MetaClasses to help reason with sponser types and capabilities.
+
+ <P>
+ Another way to load a Sponser would be to work in conjunction with plug-in support to dynamically load types that are not part of the library compilation. Sounds like a job for the CoreLinux++ Library Load
+ capability!
+
+ <P>
+ Note: In the above code example it presumes that someone has provided a MySQL persistence implementation.
+
+ <P>
+ 2. From the Sponser, get the Catalog object instance.
+
+ <P>
+ 3. Create a Store (which would require identifying the Schema to be used
+ as the roadmap).
+
+ <P>
+ 4. Fetch a Store to write and read application object instances from and
+ to respectivley.
+
+ <P>
+
+ <H3><A NAME="SECTION00067500000000000000"></A>
+ <A NAME="sec:SchmPersistRest"></A><BR>
+ Current Restrictions
+ </H3>
+
+ <P>
+ Name/Value Declarations
+
+ <P>
+ While ultimately Schemas and Concepts attributes won't be limited as to the
+ depth or types supported, the current implementation assumes most attributes
+ are of the form: Name:Value, where:
+
+ <P>
+ Name is the Key data member of the Attribute and should be of type
+ FrameworkString
+
+ <P>
+ Value is the Value data member of the Attribute and should be of type
+ FrameworkString
+
+ <P>
+ Primary Schema Declarations
+
+ <P>
+ For schemas, the following are the recognized attribute keys:
+ <PRE>
+ Attribute Key : "Name"
+ Expected Value : Unique name for this schema
+ Example : "Franks Schema"
+ Note : This is a required attribute
+
+ Attribute Key : "Collection"
+ Expected Value : The collection type literal (currently "Array" or "SetCollection")
+ Note : SetCollection is safer for insuring unique name keys, although as new collection types are added it is really up to the modeling support.
+ Note : This is a required attribute
+
+ Attribute Key : "Location"
+ Expected Value : Qualified path where schema should be stored
+ Note : This is an optional attribute, default is ~/.clfw++/schemas/"Name"
+
+ Attribute Key : "GUID"
+ Expected Value : Stringified UniversalIdentifier to be used
+ Note : This is an optional attribute, default is the system will generate.
+ </PRE>
+
+ <P>
+ with the following attribute expected to be supported in later releases:
+
+ <P>
+ <PRE>
+ Attribute Key : "SchemaClass"
+ Expected Value : The Schema class type literal to be used when instantiating a new schema, this will be stored with the Schema descriptor and will be used when reloading in new sessions.
+ Example : "FranksWickedSchemaDerivation"
+ </PRE>
+
+ <P>
+ Primary Concept Declarations
+ <PRE>
+ Attribute Key : "Name"
+ Expected Value : Unique name for this schema
+ Example : "Concept A1"
+ Note : Even though concepts can be created for other reasons, this is a required attribute if adding to a Schema
+
+ Attribute Key : "Class"
+ Expected Value : Stringified UniversalIdentifier of the type that this Concept defines representation of to the storage service.
+ Note : Even though concepts can be created for other reasons, this is a required attribute if adding to a Schema
+ </PRE>
+
+ <P>
+ with the following attributes expected to be supported in later releases:
+ <PRE>
+ Attribute Key : "Uses"
+ Expected Value : Collection type, where the collection contains attributes that describe data types of this object should reuse the storage managed by another concepts definition, therefore the nested attributes are:
+ Attribute Key : "Data Member Name"
+ Expected Value : "Concept Name"
+
+ where:
+
+ "Data Member Name" is the name of the data member that has been
+ explicitly identified in the MetaClass definition of the entity
+ being stored.
+
+ "Concept Name" is the name of another concept in the Schema
+ (which one would have to presume is the same type of the Data
+ Member).
+
+ Attribute Key : "Ignore"
+ Expected Value : Collection type, where the collection contains
+ single string values that identify (by name) the Data Members of
+ the Class that the storage management should ignore. In
+ otherword don't write or expect to read from persist.
+
+ Attribute Key : "Fence"
+ Expected Value : Collection type, where the collection contains
+ single string values that identify (by name) the Data Members of
+ the Class that the storage manager should recognize as an indicator
+ that the application whats instances of this data member to be handled
+ as a separate table/file/etc. according to it's (storage service)
+ domain.
+ </PRE>
+
<P>
! Please note that these would be considered "suggestions" that the declaration of which does not imply that a storage service would do anything with the information.
<P>
***************
*** 885,889 ****
<ADDRESS>
Frank V. Castellucci
! 2000-10-07
</ADDRESS>
</BODY>
--- 1104,1108 ----
<ADDRESS>
Frank V. Castellucci
! 2001-04-29
</ADDRESS>
</BODY>
|
