> Hi > > I am currently implementing quota for Slide. That's something which got a lot of feature requests.
> In the mailling list, I read that slide developpers were interrested in > including this feature into slide's kernel. > > So I'm searching feedback before going further in my implementation to > be sure it feets slide's developpers needs and way of coding. > > I began the implementation following advices Dirk made on an email dated > from august 2001 in which he was saying : > - the more generic way to integrate quota is to do it into > ContentInterceptor class We can do that at first. The best would be to then move it to a separate ContentInterceptor (which is supposed to be a base class) after the code needed to add the interceptors through the config files are done. Maybe we could name it UserQuotaContentInterceptor. > - user's quota and bytes used can be stored into protected properties > from user's node That should protect it from modifying it thought a PROPPATCH. In the future (Slide 2.0), I think the quota should be treated like ownership, and move to the structure, but it's not urgent. > - the algorithm could be resumed as this : in preStoreContent method > check if user has enougth space and put a lock on the user, in the > postStoreContent method update bytes used and unlock user's node. Yes. The only problems are with transactions (if it gets rolledback). Also, how is it supposed to behave when versioning is used ? > - to deal with content removing, add a postRemoveContent method to the > ContentInterceptor class. +1. > - what to do if clients don't send a contentLength ? After returning from the store, the content length in the descriptors should have been updated if it was unknown (more below). > - to allow webdav methods to indicate webdav clients the reason why the > operation failed, ContentInterceptor class must throw a special > exception that has to be catched by webdav methods to send webdav > clients an insufficient storage error code (507) We can probably subclass ContentException, as you apparently did, and add some special handling in the WebDAV layer. > So here is the begin of an implementation that takes in account (almost) > all these advices. > > I have added to package content a new Exception called > InsufficientStorageException > > I think that the best place to add a parameter to enable quota is in the > <configuration> section of the domain.xml file. > This one is read by the NamespaceConfig class that instanciates the > ContentInterceptors. Yes, except that it should be a separate implementation of ContentInterceptor (which could be made abstract to make that obvious). > I've added to the ContentInterceptor class a new contructor that has to > be called by NamespaceConfig class if Domain.xml file tells to enable quota. > > Some questions I am asking myself : > > Why is there an array of contentInterceptor instances into > NamespaceConfig class rather than a unique instance ? I thought it could be useful to associate multiple interceptors (it's supposed to be pluggable) ? > Some ContentInterceptor methods need a contentHelper and/or a lockHelper > to do their job. What would be the best : to give them to constructor to > initialize private properties or to give them as method argument ? > > Is postStoreContent method called if an exception has been raised by > preContentStore method or someone else ? I don't think so. The code for calling the interceptors is in the content helper. > Which subject, type and expiration use to lock the user's node ? I think > that with this token we can only use the user as subject but if the lock > is put by the user, it can be kill by the user, isn't it ? > > With a lock on the user's node, user won't be able to perform any other > operation ? That's likely. The Slide locks aren't fine grained locks, they're designed to be user side locks; we need internal locks here (which was one of the major new ideas I was considering in the new core proposal I talked about in the past). > What could be done with webdav clients that don't send a contentLength > header ? In the preStore, you don't know the contentLength, so you either have to reject the request or allow it and see what happens. In the postStore, the content length will be set, but unfortunately, that is after the fact. The only solution I can think of is to buffer the content to a temp file if the content length is unknown :-( Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
