[Jakarta HiveMind Wiki] Updated: ModuleResourcesProposal

[hi...@jakarta.apache.org]

   Date: 2004-04-16T11:13:09
   Editor: 63.69.231.245 <>
   Wiki: Jakarta HiveMind Wiki
   Page: ModuleResourcesProposal
   URL: http://wiki.apache.org/jakarta-hivemind/ModuleResourcesProposal

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -1,6 +1,6 @@
 = Problem Statement =
 
-I see a strong advantage for including another core module artifact at the same level as services.  I know this is a fairly big change but i dont' believe it is going away from the idea of keeping the micro-kernel minimal but rather extends the current framework so that it understands and works with resources as well.  It is debatable if resources are as important as services or should be considered at the same level.  I believe they are and that they provide something powerful that cannot be achieved through services and configurations.
+I see a strong advantage for including another core module artifact at the same level as services.  I know this may be considered as a fairly big adition but i dont' believe it is going away from the idea of keeping the micro-kernel minimal but rather extends the current framework so that it understands and works with resources as well.  It is debatable if resources are as important as services or should be considered at the same level.  I believe they are and that they provide something powerful that cannot be achieved through services and configurations.
 
 The idea of this proposal is to further explore this with some concrete ideas and examples.
 
@@ -12,17 +12,15 @@
 A POJO (Plain Old Java Object) used to perform a unit of work.  A service has no state apart from injected references to other services or resources that are needed by the service.  A service is disposable and is not persisted.  A service is not locale sensitive (although 
 it can use a localized resource and therefore produce different execution results dependent on locale).  Service instantiation is not dependent on the service implementation but only on the service model being used.
 
-This is already implemented in HiveMind.
+Services are already a HiveMind concept.
 
 
 
 '''Resource:'''
 A POJO that does not perform work put rather provides services and framework users with some resource/data. A resource 
-does have state and it is its state that is either the resource data itself or is used to gain access to the resource data.  Resource 
-data is anything used in implementation, but external to it(Strings from Properties/!ResourceBundles, data in a DB, data or XML 
-from  a file/URL, link to a JNDI/LDAP tree etc.).  A resource is localizable.  The instantiation of a resource changes depending on the type of resource and the backing store of the resource.  A resource does not have a lifecycle.  A resource could be writable, A resource has a state that tells us if it is in sync with its backing store. 
+does have state and it is its state that is either the resource data itself (i.e Messages) or is used to gain access to the resource data (i.e.Datasource).  Resource data is anything used in implementation, but external to it (Values from Properties/!ResourceBundles, data from a DB, data or XML from  a file/URL, link to a JNDI/LDAP tree etc.).  A resource is locale sensitive.  The instantiation of a resource changes depending on the type of resource and the resources backing store.  A resource could be writable, A resource has a state that tells us if it is in sync with its backing store. 
 
-This not implemented in HiveMind and i believe it could/should be and would be used widely.
+Resources are not a HiveMind concept yet.  I believe they could/should be and would be used widely.
 
 = Proposals =
 

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org