From: <km...@we...> - 2006-03-29 14:32:21
|
I had the same problem. The resource reader has problems with binaries stored in eXist or with xmldb:exist protocol. I have solved this problem by implementing a BinaryResourceReader for binaries stored in eXist. There is still a problem with the configuration of the HTTP Headers but otherwise it works. I can give it to you if you are interested. I think it is good enough for testing your CD-ROM use case.... Kai > -----Original Message----- > From: exi...@li... > [mailto:exi...@li...]On Behalf Of Jakob Fix > Sent: Wednesday, March 29, 2006 4:19 PM > To: exi...@li... > Subject: Re: [Exist-open] storing binary files in eXist > > > Wolfgang, Adam, > > thanks for your replies. Well, I've indexed all binary resources for > testing purposes, and that went easy-peasy (I had to add the mime > types for png and pdf files to the mime-types.xml file though). > > However, now that they are in the database I can't get them out ... > I'm using Cocoon sitemaps. I tried to change my sitemap accordingly, > but no success ... > > In my mind, there are potentially two possibilities: > > 1) map:generate + map:serialize -- problem here is I don't know what > serializer to use (the ones documented on the cocoon site are rather > to convert for example from svg to png/jpg/younameit.) "xml" is > refused with an Internal Server Error, "pdf" is unknown, etc. > Example: > <map:generate src="xmldb:exist:///db/{1}/pdf/{2}.pdf"/> > <map:serialize type="???"/> > > 2) map:read -- problem here is it seems the @src seems to pretend > that it doesn't know about the xmldb:exist protocol. > Example: > <map:read mime-type="application/pdf" > src="xmldb:exist:///db/{1}/pdf/{2}.pdf"/> > > > I think I'm almost there, so if someone could give me that last push > (over the cliff :-)) ... > -- > cheers, > Jakob. > > > On 3/29/06, Adam Retter <ada...@de...> wrote: > > > > > > On Tue, 2006-03-28 at 22:10 +0200, Jakob Fix wrote: > > > Hello, > > > > > > I'm trying to improve retrieval speeds for an application running from > > > CD-ROM. I have several thousand XML resources in less than ten > > > collections, and am happy with the speed they are retrieved. I guess > > > because they are all in .dbx files, and those are loaded into memory > > > at the beginning of a user session, speeds are comparable to retrieval > > > from the hard disk-based file system (even if they must be swapped to > > > the hard disk). > > > > > > Now, I have about the same number of binary resources (PNGs for > > > equations, JPEGs for figures, and PDF files) which currently reside on > > > the CD-ROM's file system. These files are only requested on demand, > > > ie. when the user requests a page on which they appear. However, for > > > some figure or equation-heavy pages, constant access to the CD-ROM > > > makes the "user experience" less desirable. > > > > > > I am wondering, and here I would be grateful for your advice, whether > > > it would be useful to add these resources to the database. Would they > > > use much more space in the database than in the file system (due to > > > some indexation)? What would the retrieval speeds be (probably, a big > > > database file would have to be swapped out from memory to the file > > > system). How would access and search requests to the actual contents > > > (the XML resources) be affected? > > > > You may store any resource in an eXist database, binary or otherwise. > > They may take up slightly more space in the .dbx than if they were on > > the filesystem, but I do not believe this is very much. Binary resources > > are not indexed. > > > > I would recommend doing a small test and seeing what your results are > > like, we store our entire web-app in the eXist db, but we have far fewer > > binary resources than you are talking about. > > > > It is of course faster to retreive the binary resource from the > > filesystem on fast storage than the eXist db as there is less processing > > overhead, however a CDROM is fairly slow so im not sure how this would > > compare?!? > > > > > Another important point: the application is to be used either directly > > > from the CD-ROM, or after being copied to the hard disk. This is why > > > I do not provide a one-file-contains-all installer, but have a very > > > lean installer that simply copies the complete application directory > > > layout from the CD-ROM. > > > > > > At the moment, it takes about five to ten minutes to install the > > > application, due to these many thousands of small files that need to > > > be copied to the hard disk. One way to remedy this problem would be > > > to stuff all these files in the eXist database, but at what price? > > > > Try it. > > > > > Thanks for your help. > > > > > > -- > > > cheers, > > > Jakob. > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by xPML, a groundbreaking > scripting language > > > that extends applications into web and mobile media. Attend > the live webcast > > > and join the prime developer group breaking into this new > coding territory! > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 > > > _______________________________________________ > > > Exist-open mailing list > > > Exi...@li... > > > https://lists.sourceforge.net/lists/listinfo/exist-open > > -- > > Adam Retter > > Devon Portal Developer > > > > Devon Portal Project > > County Hall > > Exeter > > Devon > > EX2 4QD > > > > t: 01392 38 3683 > > f: 01392 38 2966 > > e: ada...@de... > > w: http://www.devonline.gov.uk > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking > scripting language > that extends applications into web and mobile media. Attend the > live webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > |