Writing long RTs can have the downside of generating long replies ;o) On Monday 03 November 2003 23:09, Berin Loritsch wrote: > Niclas Hedhman wrote: > > 1. Naming and Identification > > 2. Versioning > > 3. Dependencies > > 4. LifeStyle > > 5. Container/Environment Requirements > > 6. Third-Party Requirements > > 7. Javadoc and other documentation. > > 8. Internationalization & Localization > > 9. Management Interface > > > > > > I don't intent to elaborate on these at this point in time, but would > > like to mention that item 2-5 is pretty much nailed down as it is today. > > Also, item 6, refers to stuff like jars/classes and resources have to be > > packaged into WAR file in a particular way. > > Ok. With 1, how do you think it should work? Right now we have the > ServiceManager to access the components we need, and we map it via > the @avalon.dependency tag. Or are you thinking of something else?
Well that is Ok within the container, but I am aiming a little bit towards the DPML aspect. How do identify a packaged component without inspection of the package content? This is fairly important if we get to operate some type of central component repos/libraries. And from that follows the "nice future problem"; If Component N, written by Niclas, declares a dependency on Component B, written by Berin, how does developer D know how to obtain Component B? > Also, 6-8 are not really addressed either. We have support for i18n/l10n, > but not in the sense of being able to provide one way to support the > resources in a consistent way. IOW, it is up to the component author to > know the keys for the i18n messages, and in no way can an application > integrator override what is packaged in the JAR. It would be very > important to export the i18n keys in a component JAR so that we can also > tool that. We would provide the values of the keys as well so that we can > turn it over to translators to do their jobs. Exactly!! The issue gets even trickier, because the ResourceBundle system in the JDK is very powerful. I18N'd icons and images also has to be kept in mind. As a Framework (server framework or not), I think we could at IDE tool level, provide "best practices" for I18N works, as well as support "language packs" "on to" components. (I think it is only a matter of loading a jar for each lang-pack for the server itself, but IDE tool must handle it.) > JavaDocs and other docs should be pointed to, not stored in the JAR itself. > That would require an internet connection (or fileshare connection) to > download the info (possibly JARed itself) and plug it in to the help > system. Perhaps this is something I should suggest to the JSR 198 team. I am a little bit split on this. When I was in the USA and had 3x45MBps connection to the Internet, for sure a central resource is good. But most of the time, I think a lot of people are offline or semi-offline (slow conn), so a local copy is good. Perhaps that a tool package "mycomp.zip" and "mycomp-doc.zip" separately, and if you want local copy.... > > Item 9, I am a little bit split over myself. Sometimes I feel that the > > container should be able to provide a Management Interface automatically, > > but how would it know what is part of management, and what is part of the > > components normal function. TBD. > > It depends on the type of management we are exposing I suppose. One of the > thoughts on this was the JMX integration with Phoenix. The container used > metadata to construct the JMX interface, and the proxy to manage the > component in question. You are probably right. But does Merlin have such support? Did tags in source create MBeans, or were they created dynamically in runtime, if so where was the metadata stored? > > First of all, I would like people to recognize that we actually have 3 > > different packages to deal with; > > > > 1. Component APIs > > 2. Component Implementations > > 3. Support Implementations. > > 4. Assembled Applications > > 5. Container Extensions > How would these five things map to the three packages? Typing error; 5 packages (it started out 3 from my current Ant build system ;o) ) > > Component API > > ============ > > The Component API specifies the programmatic interfaces and sometimes > > provides some value objects, but very little else code. > > It should (must), however, provide extensive documentation, javadoc and > > others, about the semantics, explicit or implied, of the API. > > It should probably contain I18N and L10N resources where appropriate. > Agreed to a point. If there are I18N and L10N resources that are specific > to the API, then yes. However the implementation will have a host of other > resources that are necessary for that implementation. There is no way the > API can or even should anticipate the needs of the implementations. I think we are basically in agreement. In _most_ cases, the implementation is in control of a lot. However, I have component specs that have resources being part of the spec. And in a single case, where I have one very specific API and dozens of implementations (serial port communication protocols), I "inherit" all the resources from the API... ;o) > The API portion of the JAR is fairly small typically. You mean the JAR portion of the API? > > Component Implementations > > ===================== > JavaDocs automatically inherit from interfaces or superclasses if they can > be found in the "doc path". So the JavaDocs side of things should be > easily inherited. I have never used external links or whatever they call it. I assume any URL is ok. > Docs for a particular implementation of a component should be specific to > how to configure it, or some of the advanced features that the > implementation allows. Correct. It should also define behaviours, not only usage descriptions. > The component implementation typically has meta info which identified > component level dependencies, identification, and versioning. Yes, and configuration specification, default configurations, context entries and more to come I guess. > > Support Implementations > > ================== > > The Support Implementation does not implement the Component API, but > > provides some explicit additional service to a particular Component API. > > An example of a support implementation is a Web User Interface to a > > particular Component API (or even Component Implementation). > > IOW, it is a component of a different type. It can specify alternative > interfaces to the system. Yes, that is a better way to put it. > > 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. > > I think that is as good a place to start as any. The hardest part in a > project is the first step. I recall the first (and only) time I went > repelling. The first step was the hardest, but once it was taken, it was > all downhill from there. ;P Seriously though, I would rather start with > the ideas of someone who put some thought into it, and refine and refactor > from there. See separate mail. I have started at the "server side" first, and will work backwards towards the Component API. I think things will fall in place one-by-one because of need and they can be ticked off as we go along. XP style, don't design up front, you ain't gonna need it. So, I am working to understand all the small details of Merlin (It will be Merlin only from my part) and will build a Eclipse plug-in that can do some Assembly, by inspecting Component Impl. And I take it from there... > > exit-conditions; > > 1. Packaging specifications for at least the 3 core packages > > 2. The community decides that this is not a concern and should not be > > part of Avalon core. > I prefer 1. > > 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? > > Yes. However, unless it is eclipse, I think the licensing of the IDE APIs > are unclear, so building them would be tricky. I am want to dive into Eclipse, because a few months down the line I think I need to build a new commercial app on top of it. Combine the learning with Avalon development. > > I hope I have provided some food for thought. > You sure did. Now, I hope I can some money where my mouth is, and deliver upon a promise... I love when pressure builds and ulsters erupts. 2 fulltime jobs, opensource and pregnant wife.... When am I going to have time to play games ??? Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
