> > 1.) Store the generated jp2 in a bitstream, create your own bundle, name it > whatever you want or store it next to the existing bitstream in the content > bundle if you want to also share the generated file for others to use. Then > expose the filesystem location of the file to your adore-jakota viewer. > > 2.) Store the generated jp2 file in an external directory that can be > calculated and rather than storing anything about this detail in the Item, > come up with a way to calculate the location of that file, if it exists, > then show your viewer. > I intended to use 2 because I don't want to use the jp2 in a preservation context just to get zoomable viewing for large images. I intended to run a script periodically, or maybe triggered by an event, to generate the jp2 files which should not interfere with the dspace files.
> > (1) violates the storage layer boundary of DSpace, in the future you may > not have filesystem access to that file, but your getting the benefit of > storing the jp2 file in the assetstore as well. (2) is more respectful of > the storage boundary and but doesn't assure any preservation storage of your > generated file within DSpace. > > I would choose 2 over 1 because it separates your implementation from > dspace internals, and in XMLUI can be implemented entirely in the theming > tier > > You could take your own approach and generate a bundle/bitstream with some > sort of file system reference to the file. But there may be less chance of > breakage by repo managers if its a calculated reference rather than a stored > reference. > The reference I use for calculating the jp2 file storage is <jp2 root>/<item handle>/<sequence id>/<file name>.jp2. The jp2 files will be available via a lighttpd web server to off load the file access from the dspace tomact instance. So I know how to construct the full path to the jp2 file. My issue is how do I simply save within the dspace context, the fact that I now have a jp2 derivative of this bitstream so that the item page can get a clickable link to enable the jp2 viewer. Bitstreams don't have there own metadata so I can't add anything that I could access in the xsl theme. I'm already using the description and I don't want to trouble that. I was then thinking of adding a dummy jp2 bundle, like what the filer media code does for thumbnails so that I could save the fact that a particular bitstream had a jp2 file available, but I'm not clear on how to do this for my needs. Any help here would be appreciated. > > I like (2) and if we had the development resources, I'd promote the idea > that we should have more than one possible "storage" tier for DSpace, > allowing maintainers to create there own separate storage locations for > derivatives that may require specific storage/access requirements and access > to by other applications. The work you do here could go to producing such an > API. > That's fine by me but I would need some hints on which approach might give the best result. John > > Cheers, > Mark > > On Wed, Apr 21, 2010 at 2:55 PM, John Preston <byhisde...@gmail.com>wrote: > >> Hi, I am seeking a little guidance here. I am setting up adore-djatoka >> with dspace 1.6. I have a dsrunable java class that goes through my >> collections and looks for all large image files and creates jpeg2000 >> versions of these under a particular directory. After creating the jp2 >> version of the file I want to create a dummy file in a new JP2000 bundle >> that I can manipulate within the xmlui to add a clickable link that will >> popup the adore-djatoka viewer to give access to the jp2 file. >> >> My question is how best should I store the jp2 file location, using a >> specific jp2 bundle say, to be able to manipulate it within the xmlui. Also >> how would the xsl code like like to access the name of the jp2 file location >> >> John >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> DSpace-tech mailing list >> DSpace-tech@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dspace-tech >> >> > > > -- > Mark R. Diggory > Head of U.S. Operations - @mire > > http://www.atmire.com - Institutional Repository Solutions > http://www.togather.eu - Before getting together, get t...@ther >
------------------------------------------------------------------------------
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
