> >> I need the Container to call save() on the components at any time it > >> is needed. > >> For me, each Component is an instance of an app, and since the system > >> does autosaving, it needs to ask the Component to save when needed. > >> > >> What does this have to do with startup-shutdown? > > > > > > startup/shutdown is the are that avalons lifecycle management deals with > > (ie what we term lifecycle interfaces). This is the only thing we > > standardize on (at least now that Component is going way of dodo). > > How about Recomposable, Recyclable, etc? > You mean that they are there but the call times are container specific?
nope. Part of the lifecycle; not container specific. > > In the past we have specified some structural interfaces (ie Component, > > Block and BlockListener) but except for BlockListener they have all been > > killed. Note that BlockListener does not require any changes to > > lifecycle interface sequencing. > > > > Other "feature" interfaces like Soapable (export via SOAP), Saveable > > (persist somehow) etc have also been implemented without modifying the > > lifecycle of components. > > Oh well, it's a terminology thing then. > I call lifecycle *all* of the callt that the container makes to the > component. You seem to intend only startup-shutdown. save() has nothing to do with the life of a component (it's contract is only that it can only be called between start() and stop(), as for most such "lifecycle extensions"), so it is slightly different from the lifecycle we have defined. > > What you are asking for is an container that you can easily extend to > > add features to. > > Yup. > An possibly make that portable somehow between containers, maybe by > making cooperation or delegation of component handling a standard part > of any Avalon savy container. we're just starting on container interop, and we should focus on getting current functionality through before adding stuff like this. I think it is not wise to implement this in all containers, as it adds some "bulk" to the container which you might not need. in the future, some kind of "standard" would be nice, though =) - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
