> Jean-Philippe Courson has provided patches and discussion for making the > org.apache.slide.content.ContentInterceptor more usable. As there were never any > implementations of that class (at least none that I'm aware of), usability of > it's API has not been tested in the real world. > > Jean-Philippe worked on a UserQuotaContentInterceptor to add support for user- > quotas to Slide, based on the ContentInterceptor API. This usage revealed some > serious shortcomings of the API that we should fix as soon as possible. > > As these changes qualify as API changes, I hereby call for a vote to determine > agreement/objections in general, as well as opinions on how far the changes > should go. > > Most of the proposed changes have been submitted by Jean-Philippe as patches, > and I've reviewed and partially enhanced these patches, as well as incorporated > them with my local copy, so there are only yes/don't care/no options in this > vote. > > [apologies in advance if I've missed some formal conventions on votes] > > 1. Enable ContentInterceptors to be configured via parameters > [X] +1. I agree with the change. > [ ] +0. I don't care. > [ ] -1. I don't agree, because:
(obviously) > 2. Add a postRemoveContent() method to ContentInterceptor, to be > called when the content of all revisions or one particular > revision of a node has been removed from the namespace > [X] +1. I agree with the change. > [ ] +0. I don't care. > [ ] -1. I don't agree, because: > 3. Allow the preXXX()/postXXX() methods of ContentInterceptor to > throw exceptions, in particular: AccessDeniedException, > ObjectNotFoundException, LinkedObjectNotFoundException, > ObjectLockedException and ServiceAccessException. This is to > allow interceptors to truly intercept content operations, and > to not force implementors to "swallow" important errors. > [X] +1. I agree with the change. > [ ] +0. I don't care. > [ ] -1. I don't agree, because: > > 4. Allow ContentInterceptors to access the namespace via a > NamespaceAccessToken to permit operations like logging to the > namespace logger etc. > [X] +1. I agree with the change. > [ ] +0. I don't care. > [ ] -1. I don't agree, because: There's the possibility of abusing this feature, though. > 5. Make ContentInterceptor an interface, and provide a basic (mostly > empty) implementation as AbstractContentInterceptor, to make the > API contract clearer. (*) > [X] +1. I agree with the change. > [ ] +0. I don't care. > [ ] -1. I don't agree, because: > > 6. To round up the ContentInterceptor interface, also add the methods > preRetrieveContent() and preRemoveContent(), so that all event > types have pre and post hooks. (*) > [X] +1. I agree with the change. > [ ] +0. I don't care. > [ ] -1. I don't agree, because: > > 7. Implement the agreed upon changes in the SLIDE_1_0 branch for > the upcoming release 1.1.0, as well as in the HEAD branch. > [X] +1. I agree with the change. > [ ] +0. I don't care. > [ ] -1. I don't agree, because: > > (*) The last two points would qualify as API changes that might not be strictly > necessary at the moment. But as I stated before, if we're changing the API > anyway, we might as well try to get it right. ;-) Yes, I agree. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
