> -----Original Message----- > From: Daniel Frey [mailto:[EMAIL PROTECTED] > > >Your frame can either be an actual Avalon component itself, or you can > >embed Merlin in the frame. Either approach is workable. > > What are the pros/cons for the two strategies? I think, the first solution > is given in the composition tutorial, isn't it? Do you think you could > share > an example/real life application for the second solutions with me?
I would suggest going with a wholly Merlin solution, that is, your frame itself with be inside some Avalon component. While this approach will be a slight departure from what you may be used to (it can be a different way of programming) you take advantage of Avalon's features the whole way through your application. This translates into a more consistent design. As for how to do this, if no one else gets to it first, I'll try to put something together in our HOW TO section: http://wiki.apache.org/avalon/HowTo > I think the central repository mechanism is genius (opposite to some > other opinions). I agree. However, in some cases it does work as well (ie- servlets). So there is a need for us in Avalon to be flexible. > >As for WebStart, Stephen had a working Merlin/Webstart example at one > >point. I'm not sure what state it is in now. > > I think webstart has the ability to generate zipdiffs. I think this is > great too in order to minimize traffic. I think the repository component > has > to be replaced by webstart. If there is an example available here, I would > appreciate it. Actually, you can get away with using *less* traffic with the Avalon repository package and with some of Merlin's block loading features. Rather than explain it here, I'll put up a comparison between WebStart and Avalon Repository/Merlin on the wiki. I'll post something here when I finish it (today or tomorrow). > At this stage I also have to think about an alternative to the plugin > mechanism mentioned initially. I could imaging that an Avalon driven > plunging-mechanism is simply reduced to configure which artefacts should > be > loaded, instead of putting them into a plugin-directory. The Avalon > Repository Reverence Implementation might come in here handy. If you have > experiences with configuring plugins, I'd be interested in these too. I think I'd need a better idea of what you mean by plugins and how you want them loaded/handled etc. Perhaps the best option would be to create a "plugin" handler that would be an Avalon component. That way you could have more control over the plugin mechanism itself. J. Aaron Farr SONY ELECTRONICS DDP-CIM (724) 696-7653 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]