Further on an indexing implementation for MySQL. Really, the only thing I need to decide before posting this (and how should I do this?), is where to get the meta-meta properties from (i.e. what is the data type of a given property). For the moment, how does it seem to just use Domain.xml and take it from there? [I'd put an extra element/block in the store element]
>> -----Original Message----- >> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] My idea was to have a group of authors working on the >> > same >> > set of files, only allowing offline content changes if the file's >> > checked out, rather than the local/remote model that's >> standard. I'll >> > explain why if anyone's interested, but in another mail. >> >> This seems like a job for a DeltaV-aware client. It is. >> > (architecturally I find >> > Slide a completely impossible act to follow. Which makes >> me a little >> > shy). >> >> Slide is a complex beast, probably too complex in some areas I agree. By "impossible act to follow" I meant very, very impressive, in terms of providing maximum separation/opaqueness (via tokens & helpers) to a problem that's highly interdependent. And yes, it took me a little while to work out what was going on. >> > Index table creation/rebuilding. >> > >> > - the better way to do this would be through Slide Admin. But >> > >> > 1. is slide admin maintained? (no). do you want someone to >> maintain >> > it? >> >> In my experience a command line tool is much more useful than a >> web-based tool because sysadmin are much more worried about web >> interfaces thru SSL than with command-line based ones over SSH. I tend to SSH and then lynx on localhost, because any reasonable-sized admin tool means a UI of some sort, easiest in HTML. But yes, point taken. >> >> > 2. is there any way in Tomcat/servlet containers to define webapp >> > dependencies, and hence classloader access across webapps, >> rather than >> > "copy it all into common", which sort of defeats the purpose of >> > webapps? >> >> no. servlet contexts are meant to be completely isolated >> (which is the >> reason why webapp composability cannot be achieved [and the >> reason why >> i designed cocoon blocks, but this is another story]) >> >> > My actual implementation uses a parameter in the nodestore element >> > which >> > tells the adapter whether or not to rebuild the index >> table on adapter >> > initialisation. >> >> Why would you want to do that? [curious] If you added this type of query support after creating your slide tables - or if you added new properties - or whatever. This could be done by an index verification routine after adapter startup, but for testing at least I preferred manual control. But I think a more general problem remains: there's no way to tell Slide (as server application) to do anything, when it's installed as a webapp, except through the Webdav protocol --- wait a sec, how about MBeans?? You could hack in the protocol itself (I remember reading about a proposed method which was just server-specific commands), but...nasty. >> >> > The ideal way to support index building would, I think, be >> to define a >> > "resource" path in the filesystem itself, which the >> indexing services >> > use to determine the data types and tables for the various >> properties, >> > i.e. a folder >> > >> > /files/_resources >> > >> > containing >> > >> > dav.xsd >> > myXMLNS1.xsd >> > ... >> > >> > which maps from xml data types to the various db types....and, of >> > course, allows validation checks if desired. (jakarta-db-ojb??) >> >> hmmm, not sure about this... sounds a little hacky to me. Well, if we want creationdate, modificationdate etc to be indexed as dates, the indexer needs to know this. And since the properties are xml data (even though in the dtd all the simple fields are #PCDATA), one way to express the data type of the properties would be in a schema. I can't think of any more general way to do this. You could define an extra block in Domain.xml for this, but I'm thinking a little way off of a mime-type > properties mapping, which is hierarchical [i.e. DAVResource > text > text-xml > text-xml/x-application-schema), with the various schema extending their parents, and providing the additional properties you'd want to index for that particular mime type. >> >> > >> > (!) Rather than use interceptors, every method in the adapter that >> > modifies the underlying RDBMS also reindexes the file. Principally >> > because my client is mostly interested in the "meta-meta" >> property of >> > whether anything (acl, lock, properties) have changed, so >> > as >> > to cache successfully. Change propogation to children I >> simply ignored >> > (because for a relational system, which is what I was >> after, there's no >> > such thing as a definitive parent/child relationship). >> >> I'm not sure I understand what you mean here, can you elaborate more? OK. By "relational filesystem" I meant a hierarchical view of a filesystem where the "model" structure , folders & children, is dynamically constructed from an underlying traditional filesystem, e.g. a standard Slide store. So you can show a view - say /users/john/recent/projects/myProject of the total file system which is filtered to show only files for which john is the editor and have been modified in the last 10 days. Sort of like workspaces, but completely property-defined. And that "view" (from the data point of view) is just a normal folder (to the client). I've just got it working, and I'm already finding it useful. >> > ? How to search for meta-meta properties (i.e. change/delete >> > notification). >> > I defined some new properties which are only evaluated >> for infinite >> > depth searches on the filesystem root ("/") >> > It's wrong, and inelegant, among other things it means >> SEARCH gives >> > you info which PROPFIND doesn't, because in Slide the >> store has much >> > greater control over SEARCH than PROPFIND. >> > >> > Ideally, I think, the real solution would be a >> PropertyProvider that >> > plugs into the store directly. But whole slabs of >> > src/webdav/server/org/apache/slide/webdav/util >> > >> > use statements like the following: >> > >> > AbstractResourceKind.isComputedProperty(propName) >> > >> > which means any subclassing of the property provision >> section of slide >> > would mandate refactoring of these classes. >> >> Not sure I follow here either, can you elaborate more? NodeProperty creation/evaluation [for anything other than a SEARCH request] is performed by classes in org/apache/slide/webdav/util which don't allow subclassing because of various static methods like the one above. In an old version of Domain.xml there were some commented-out parameters which would have allowed extensions to the property mechanism (i.e. which class implements AbstractResourceKind), but the code of other classes in the webdav.util package would have meant you'd have to replicate the whole package, almost. >> > Which sort of begs the question, why not allow PROPFIND to >> just call a >> > SEARCH, if appropriate? (And yes, I have got classes to generate a >> > SEARCH body). >> >> that was I was planning to do as well, yes. >> >> > "KNOWN ISSUES" >> > these aren't truly critical, because anything this search >> > implementation >> > can't handle it just throws back to the default implementation >> > - doesn't allow ACL/Lockdiscovery in the select >> > - only supports depth 1 (or infinity for meta-meta) >> >> Can depth n be implemented with n queries on depth 1? what >> about joins >> on parent/child relationships and let the DB do its query >> optimization >> job? sure, although for multiple depth you'd be doing select ... where uri_id in (select...where in(select where in(select where)))) I was almost thinking caching (indexing) the child-parent relations up to depth 4 or 5 might be faster (although moving files would be slower) >> >> > - (Critical) doesn't resolve links/binding (but doable >> completely in >> > SQL, I just need to check out BindingStore) >> >> this would be a must to have if we start using binding seriously. Yep. >> >> > /////////////////////// >> > >> > Any feedback on the above would be truly appreciated. Particularly >> > from Stefano Mazzocchi. >> >> Hope this helps. >> >> Anyway, thanks much for your contribution it is greatly appreciated! Thanks very much. >> >> -- >> Stefano. >> >> Nick --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
