Re: Loom viability

Sorry for the delay in responding, we're all pretty busy at the moment  
:)

On Dec 15, 2003, at 12:45 PM, Terry Laurenzo wrote:
> Forgive me if parts of this message are redundant or have been  
> answered before... I am new to this list.  If any part has been  
> answered, please point me in the right direction.

perhaps partially, in the list archives.. but i'll answer your  
questions here..

> When is a Loom release planned? My shop and I are what could be called  
> "Phoenix refugees".  We have a large investment in the Phoenix  
> platform.

yup, thats the position my company is in too... we are heavily using  
Phoenix and to switch to something would be counter-productive.

we're (very) slowly working towards a 1.0 release of Loom. i don't  
think there is much more that needs to be done before a release, so  
maybe we can pump it out soon.

> It seems that radical changes of direction happen regularly without a  
> huge eye towards maintaining compatibility (this is just an  
> observation... please don't flame me).

without a doubt. there have been several shifts in Avalon that are  
good, but were a pain ( Loggable -> LogEnabled and Compsable ->  
Servicable for starters)

> So, I am leaning towards adoption of Loom to preserve our existing  
> investments and as a platform for the future.  However, I have been  
> burned once by adopting pre-release Phoenix capabilities and I would  
> like a clear statement of direction.

Our issue tracker has the best list of things that are on our radar at  
the moment,  
<http://jira.codehaus.org/secure/IssueNavigator.jspa? 
reset=true&mode=hide&sorter/order=DESC&sorter/ 
field=priority&resolutionIds=-1&pid=10210&fixfor=-1>

> Are there any plans for supporting such a paradigm?  If not, are there  
> plans for at least shoring up the internal Loom kernel structures so  
> that a third party implementation such as this would be relatively  
> stable from version to version?  Assuming you are not opposed to such  
> an idea, would you care for code contributions that allowed Loom to be  
> run in this embedded mode?

<http://jira.codehaus.org/secure/ViewIssue.jspa?key=LOOM-32> looks  
kinda like what you are asking about.. embedded mode is very similar to  
nesting Loom instances, which is also on our radar. so yes, we have  
plans to go in that general direction, and code contributions would be  
greatly appreciated!

> 2.  One of the features which I believe made Phoenix attractive  
> arrived in the 4.1 developer branch.  This was the notations around  
> specifying maps or arrays of dependencies (appending [] or {} to the  
> role).  It seems that the rest of the Avalon community is stuck in  
> some kind of religious war revolving around whether ServiceSelector is  
> evil and what to do about it.  I thought that the multi-dependency  
> notation was a good solution to this problem that no one seems to like  
> but clearly needs a solution.  Is this functionality sanctioned in  
> Loom?  Are you planning any extensions to it?

It is in Loom, but I don't know of any planned extensions (does it need  
any?)

> 3. It is clear that Loom and the JContainer project are intended to be  
> complete forks of Avalon.  My observation is that DNA is analogous to  
> Avalon framework (with much simplified names).  This is all well and  
> good, but is there a commitment to keep Loom capable of hosting  
> components/blocks written to the Avalon framework interfaces as  
> opposed to the DNA interfaces?

For the foreseeable future, yes. There are plans to allow the hosting  
of components written to other APIs, but the Avalon API won't be  
deprecated as long as there are users (and useful components to use! :)

lemme know if you have any further questions!
-pete