Re: enhancements/fixes for slide 2.1
Eirikur Hrafnsson <[email protected]>
| Newsgroups | gmane.comp.jakarta.slide.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Max and thanks for the quick reply. The optimal solution would of course be if Slide 2.2 would come out sooner than later with your patches... However I'm already using some stuff from Hippo actually (extractors) although I hadn't thought about using your custom build of Slide since I thought it was plain old Slide 2.1. : ) What stuff from 2.2 have you back ported? I ask because I have an old snapshot build from Slide head running under our webapplication platform (IdegaWeb) and I'm wondering if your stable build might be better. I need Lucene indexing with DASL working correctly and the triggers/event system... Offtopic > One of the guys here at Idega wanted me to ask you also if the Hippo team is considering developing a JCR plugin on top of Slide? best regards Eiki, Idega Software ____ Eirikur S. Hrafnsson, Chief Software Engineer Idega Software, http://www.idega.com Iceland On 7.7.2006, at 11:33, Max Pfingsthorn wrote: > Hi, > > Right, I didn't commit that yet. I've been very busy with our in- > house development of a completely new document repository, so I > haven't had much time to turn my slide patches into something > workable... The problem I have is that we use avalon to start > slide, jetty, the openjms server, and a few other things, and most > of our components which I mentioned before depend on it. > If you want, you can have a look at the code of ours at > > http://svn.hippocms.org/repos/hippo/hippo-repository/trunk/ > > most notably > > http://svn.hippocms.org/repos/hippo/hippo-repository/trunk/ > components/excalibur-slide/server/ > > Sorry that there are some org.apache packages, I know that is not > really good form, but the way slide core behaves with access > modifiers and things made it necessary. The interesting bits for > you are actually in that org.apache.slide package, which include > Lucene based OrderBy and BasicQuery implementations. The > nl.hippo.slide package contains some indexing code, most of which > is a backport of the slide 2.2 lucene indexer. > > I've also patched my slide checkout a little so this thing builds > against it. Those changes aren't available online yet (hopefully > soon), but the binary is available on our maven repository. > > http://repository.hippocms.org/maven/jakarta-slide/jars/ > > Some build instructions are here: http://www.hippocms.org/display/ > CMS/Building+Hippo+Repository+from+Source > There is also a binary build of our "repository": http:// > www.hippocms.org/display/CMS/Installing+Hippo+Repository+Binary > You can use that one to testdrive the enhancements a little. > > I hope that helps a little. > > Bye! > max > > -----Original Message----- > From: Eirikur Hrafnsson [mailto:[email protected]] > Sent: Thursday, July 06, 2006 18:49 > To: Slide Developers Mailing List; Max Pfingsthorn > Subject: Re: enhancements/fixes for slide 2.1 > > > Hi Max and Slide list... > > I was wondering if your fixes to the DASL ordering and limiting > have been added to Slide yet? > I'm working with a 6 months old Slide build or so and ordering > seems to be broken although limiting works. > > Ordering by getlastmodified e.g. in this DASL search does not order > the results: > > <D:searchrequest xmlns:D='DAV:' xmlns:S=' http://jakarta.apache.org/ > slide/'> > <D:basicsearch> > <D:select><D:prop><D:getcontentlength/><D:creationdate/ > ><D:displayname/><D:getlastmodified/></D:prop></D:select> > <D:from><D:scope><D:href>files</D:href><D:depth>infinity</D:depth></ > D:scope></D:from> > <D:where> > <D:and> > <D:or> > <D:contains>***</D:contains> > <S:property-contains><D:prop><D:displayname/></ > D:prop><D:literal>***</D:literal> > </S:property-contains><S:property-contains> > <D:prop><D:creator-displayname/></D:prop><D:literal>***</D:literal> > </S:property-contains> > <S:property-contains><D:prop><D:comment/></D:prop><D:literal>***</ > D:literal></S:property-contains> > </D:or> > <D:not-is-collection/> > </D:and> > </D:where> > <D:orderby><D:order><D:prop><D:getlastmodified/></ > D:prop><D:descending/></D:order></D:orderby> > </D:basicsearch></D:searchrequest> > > > > On 20.2.2006, at 11:09, Max Pfingsthorn wrote: > > > Dear all, > > I hate to reply to myself, but I was just wondering if the offer > still stands... I would love to help out and it would be great if > you guys gave me that chance! > > Best, > Max > > > -----Original Message----- > From: Max Pfingsthorn > Sent: Tuesday, February 14, 2006 11:20 > To: Slide Developers Mailing List > Subject: RE: enhancements/fixes for slide 2.1 > > > Hello everyone! > > > -----Original Message----- > From: [email protected] [ mailto:[email protected]] > Sent: Saturday, February 11, 2006 12:33 > To: 'Slide Developers Mailing List' > Subject: AW: enhancements/fixes for slide 2.1 > > Hi Hippo! > > > Hippo is just my employer ;) Just call me Max. > > > Fromm y point of view it would be great if you would become a slide > committer and could add patches to the sources directly. If you are > interested, I would start a voting thread on this mailing list. > > > That would be great! I would be very honored. > > > I think most of your patches are very helpful for the slide > > community. > > Thanks, I do my best. > > > One comment to your patches regarding the lucene-based search: > If you use lucene directly to limit the results this might > > cause some > > trouble if you are using acl's. The acl's get evaluated after slide > retrieves the search result from lucene. If you for example > specify a limit > of 10 results and the user executing the DASL-request has no > permissions to > read half of them, he would only get 5 files even if he > specified to get 10. > So it would be very helpful to have a configurable switch to > select if you > want to have a fast system (with the risk of wrong number of > results) or a > slower search with correct results. > > > Actually, you cannot tell Lucene to only return so many hits. > The nice thing about Lucene's Hits datastructure is that it > lazy-loads data from the index. That way, it can return the > full structure, without much of the overhead, and you can > decide how many you access yourself. What I do is to iterate > through the Hits until I generated as many authorized results > as needed. What makes it fast is that sorting is done in > Lucene as well, so even then, you don't have to load all > results in memory and sort them there as it's done right now. > > > Why have you used JMS to notify cocoon? Have you had a look at the > Notification abilities in the slide webdavlib? > > > I wasn't aware that the webdavlib had such a feature. Also, > when I joined the team here, JMS notification was already implemented. > > Bye! > max > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > >