Aron wrote: > From: Daniel Frey [mailto:[EMAIL PROTECTED] >> 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).
?Less? traffic than the zip diffs? Cannot imaging how this would work? >> 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. Now, that I have worked a little bit through the examples and tutorials, I've got a precise idea on how this should look like. We actually have already a big application, who's roles could look like this in Merlin's world: - The entry point is a simple Merlin container that runs the application. It contains no GUIs or stuff like that. It's a simple coordinating entry point. - Other services have to be there right away during start-up of the application. Each of them in its own container: a resource manager, a splash manager, an action manager, a main frame. The application looks them up, and builds a context object out of them, except for the splash manager, which is not used any more. - Somehow I configure some "modules". Modules are nothing else than plugins, or in Merlin's language: containers (or components). The modules interface allows getting a JPanel that is placed within the main frame. At this point I would have written a module manager (we actually have already one), that first is responsible to instantiate the module and second place the JPanel within the main frame. Luckily, Merlin reduces the module manager to the second task. I think the module manager has also to be associated within the main application and to be added to the context. - Each module receives the context (Contextualizable). Each module registers its actions in the action manager (Initializable). I think to start with, the "somehow I configure" could be a simple configuration file - like a block, or simply a block - that associates some components (or containers). Later on, the manager could be kind of a GUI that allows for dynamic configuration. Is Merlin able to runtime-plug-in modules, or is a restart in any case needed? I do not know whether the use of Merlin is intended to be like this. I think it comes in handy to be used as fine-grained as described above. But might be that this makes no sense in terms of Merlin components, maybe because it's too overheady, and a monolithic container with all the managers as components would be more accurate, or a simple monolithic container would be the right thing. However, I would appreciate if Merlin's use is exactly for that kind of fine-grained resolution. What do you think? All suggestions/experiences with these kinds of applications are welcome! Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
