Re: Loom viability

Thanks a lot for the info!  I'm pretty busy at the moment, too, but  
I'll troll through the issue database and see if there is anything that  
I can work on...

>> 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?)

I guess it doesn't need any extensions, but the state that this feature  
was in for the last 4.1 Phoenix snapshot I got (admittedly a long time  
ago) was pretty shaky.  It seemed as though practically the entire  
Phoenix kernel assumed one-to-one relationships between components and  
this feature was something of a square peg in a round hole (but a much  
needed square peg!).  I remember submitting some fixes to it back in  
the day that made it useable... I'll take a look at source for this, as  
I was pretty familiar with it and aware of some of the areas where it  
needed improvement.  If I recall, the particular limitation that it  
suffered from was that you had to declare at least one instance in an  
array or map dependency... there was no way to get back in empty array  
or map from the service(...) method.

Anyway, thanks for the time, and I'll go poking around.

Terry

On Wednesday, December 17, 2003, at 07:39 AM, peter royal wrote:

> 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<smime.p7s>