On May 27, 2008, at 10:07 AM, Dorothea Salo wrote: >> I am wondering how DSpace handles structured sets of integrated >> files that >> are code based such as programs written by computer science >> students, e.g. >> games, etc. that may have actual language code interacting with >> image files, >> for example.] > > We ran into this in the case of Flash learning objects that called out > (via relative link) to images and movies stored alongside. > >> Is it possible to put these types of files in DSpace in such a way >> to access >> the files, launch/use the game? > > Sometimes. I've managed to get things like Java applets to run if the > entry point is an HTML file, because of DSpace's website-handling > code. I'm not particularly sanguine about their continued functioning, > however, I admit. Straight-up Flash apps/vids accessed directly from > DSpace don't work, because DSpace has no reason to fetch files > referenced from the Flash. > > It might be possible to mod the existing HTML-handling code to deal > with this problem; we're looking at this in our upgrade to 1.5, but it > may drop off our priority list. > > Dorothea >
To be honest, if its anything other than HTML I would focus on packaging it in an archive format of some sort and placing that as your bitstream. Even in the HTML case I'm a little wary of DSpace's solution here as it can be brittle and complex to maintain proper linking behavior as Dorothea does point out. It you do want to store a complex object like a java program in a DSpace Item and "do want it to be executable". , I.E. If your trying to utilize tools like Java Web Start, they can always place the jars (java archive files) as bitstreams for the item first and then link to them from a JNLP definition file somewhere. That jnlp definition file could be stored in the Item as well and reference the included bitstream "relatively". But this is about as far as I would take it. The challenge to consider in the case of executable programs is that over time, the client OS/Applications will be evolving and will eventually render the provided application not runnable on the current popular platforms, consider trying to run a Windows 3.1 program on Windows Vista, its a gamble if it will run or not. Likewise with archived websites that are not well formed and do not meet w3c standards, eventually browsers may not properly handle the website rendering because they have evolved to meet new standards, javascript programs that ran in browsers in the late nineteen- nineties have this same problem today. With these issues in mind, its important to get the point across that these programs need to be: 1.) packaged with as many of the platform dependencies as possible, avoiding external linkages to third party dependencies that may disappear over time. 2.) Provide as the archived object, the original source of the program used to generate the executable as a documented account of what the program actually does do. This will help others interested in the program and its capabilities to recreate an executable copy of it on the latest greatest platform or emulation environment. Cheers, Mark ~~~~~~~~~~~~~ Mark R. Diggory - DSpace Developer and Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
