commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <hkrishnasw...@comcast.net>
Subject Re: [HiveMind] HiveMind ideas
Date Wed, 03 Mar 2004 20:00:43 GMT


Howard M. Lewis Ship wrote:

>>>From: "Howard M. Lewis Ship" <hlship@comcast.net>  
>>>      
>>>
>>>>- I believe your placeholder for version checking is at the 
>>>>wrong level.
>>>> I think versioning should be at the service interface 
>>>>        
>>>>
>>level, not the
>>    
>>
>>>>module level.  Isn't that how Eclipse does it?  What are your 
>>>>thoughts here?
>>>>        
>>>>
>>>I'm pretty sure module level makes sense. Eclipse does it that way.
>>>      
>>>
>>Right you are -- I misremembered.  However, let me expand a bit on my
>>theory.
>>
>>A HiveMind module may supply lots of service interfaces.  Now, you
>>*might* want to manage all of these services' versions with a single
>>module-wide version -- as you have it.  But you might instead want to
>>manage their versions individually.  Why?  Well, otherwise your 10
>>stable services will appear to have changed incompatibly when you have
>>to bump your module's version number to satisfy your 1 
>>rapidly changing
>>service.
>>
>>I'm anticipating being able to specify the version number 
>>required when
>>wiring up a service, and when providing an implementation, with the
>>meanings for version numbers that Eclipse uses.  (Namely: a change to
>>the major number means a potentially incompatible change, and a change
>>to the minor number means backwards compatible.)
>>
>>This seems useful to me, when trying to manage lots of independently
>>developed services, which is what I'm trying to do.
>>
>>    
>>
>
>Rapdily changing interfaces?  Not just implementations, but interfaces? That sounds more
like a
>alpha cycle than a full release cycle.
>
>I'm beginning to see that your interfaces will stay simpler and more stable. HiveMind
gives you a
>lot of tools (on-the-fly service construction, dependency injection, event notifications,
stateful
>service models) so that its' very easy to create simple facade interfaces around more
intracate,
>collaborative services.
>
>Back to your issue. One solution is to use a more fine grained approach; have many seperate
modules.
>
>I think, to support that approach, HiveMind may need a way to break the "one jar == one
module"
>approach.  Perhaps an element of the module descriptor could be a path to *additional*
module
>descriptors to read.  
>
>In other words, you can have a "myco.mypackage.public" module and a "myco.mypackage.private"
module
>packaged together in a single JAR.
>  
>
I am a big +1 on this approach. My modules are already too big with a 
lot of configurations.

On a related topic, Geoff asked about private services a few days ago - 
services that should not be available to clients (via 
registry.getService() I presume), only to other services via injection. 
What do you think about that?

>--
>Howard M. Lewis Ship
>Independent J2EE / Open-Source Java Consultant
>Creator, Tapestry: Java Web Components 
>http://howardlewisship.com
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>  
>

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


Mime
View raw message