Create a sharedstorage module under applications and store all the implemenations in this module.
[X] +1 (YEA) BUT -1 on the name
In favor of moving all change implementations under one package.
-1 on the name, for now. I think we should not refer to 'storage' but to 'changeinterface' or 'messaging', or 'eventsdispatcher', or something similar, just so we may, in the future, have means to send events other than those concerning cloud changes.
I also think the SharedStorage class should probably be renamed for similar reasons. We may even have to concider, in the future, whether 'MMBaseChangeInterface' works as a name but that is a step too far at this point.
Imo classes should go under an 'implementation' package under the package where the core classes/interfaces are.
Repackage remaining sources to org.mmbase.storage.shared
[X] +0 (ABSTAIN ) BUT -1 on name
While I am in favor of renaming packages (see Optimization project), I think it may be better if we first think through where, in a future MMBase (say, the mythical 2.0 version) we want the package structure to be.
I.e. I can imagine we want a org.mmbase.core package, and an org.mmbase.core.messaging package. Or we migth want it under the 'utils' package.
Hence while I am not negative about moving the code, I think it may be too early to settle on a proper name yet. So while I'm not to step in the way of progress, my advice is to do this at a later date.
At any rate, I am not really eager on putting it in the storage package, for reasons outlined above.
If a package name is chosen, it should probably match with that of the implementations.
If you do desire tor ename, my suggestion would be: core classes: org.mmbase.messaging application package: org.mmbase.messaging.implementation
though right now we may best stick to org.mmbase.module.core.change and org.mmbase.module.core.change.implementation
Gomez
_______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
