Avalon today is 100% about CODE and METADATA.
Avalon shy away from all kind of RESOURCES, whether they are pertinent to the Avalon context or not. I don't know if this intentional or not.
Not going into the rest of the RT (need more time to digest), some background perhaps...One reason that has often been quoted is that, whereas class/code management, and to a lesser extend configuration/metadata management, is an area where there exists lots of expertise. We know relatively well how to deal with those and come up with a solution that works for the vast majority of problem spaces.
More "general" resource management is much more difficult, as there is no "general" kind of resource; just about every resource that is only very loosely coupled tocode will be more specific to a (category of) problem space(s).
Since, with avalon, we have the tendency to always strive to the "very" end of the "generic" scale, we've always kinda shunned away from attempting to deliver generic resource management.
That does not take away that there is a real *need* for a/some resource management solution(s) that integrate(s) with the rest of the platform. Cocoon is a perfect example (being focussed about "content", which is definately classifiable as a "resource"), and there's many more (like the business rules/workflow area where often a "rule" or "process" is more like a generic resource than like concrete code, the GUI/TUI/WUI world, ...)
<snip/>
I have started on such a tool several time<snip/>
I would like not to go into specifics about what _I_ believe to be a good packaging specification for the above 3 (I haven't been thinking too much about Container Extensions and Support Implementations), but let everyone digest what I have just written.
If I'm to fully digest all the implications of your words, I think I'll need a lot more "context". I learn well by example :D
1. Packaging specifications for at least the 3 core packages (api, impl and app).
or
2. The community decides that this is not a concern and should not be part of Avalon core.
even if it is not part of "core", it can be a "standard extension" or something like that. The packaging stuff fits the avalon charter pretty well. IIRC, we already decided in the past that this is an area we're willing to delve into :D
And in the event of 1., the follow-up question would then be, Is it in Avalon's interest to host IDE tools for Avalon development?
sure! If there's people to do the work, again, IMO it fits our charter, so I think we're pretty open that kind of thing.
All this is in pretty generic terms, of course. Personally, this is not my area of interest atm, but I know there's several people quite anxious to work on the same things as you :D
cheers!
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
