Hi I just noticed this post. I have been giving the same issue some thought.
I do actually not like the file protocol for this use. First, there are the security risks. You could, as a remote operator add a file that is local to fedora as a datastream, even if you could not read this file. All because file:// is resolved on the Fedora server. To add datastreams require some admin rights, but if you have some GUI where users can create new objects the users have these rights. I do not know if this is a big issue, but I do not like to worry about the implications of it. Second, fedora does NOT require that you use the client to upload the file beforehand. It requires a url to the file. Why not just put a webserver up to present the file directory. Then you will have urls of the form http://localhost:8080/Tetabytedisc/dir/dir/file for each of the files. Regards On Fri, 2009-05-29 at 09:57 +0200, henk van den berg wrote: > Hi, > > Thanks for the fast reply and sure I voted for the issue. > > A few moments after I posted the original message to the mailing list I > noticed that the DatastreamManagedContent.TEMP_SCHEME is really just mend > for Fedora internal use. Oeps, my original file had passed away after being > ingested by Fedora. > > Still I need to get this batch of data files into Fedora. Did some > investigation on speed of various FedoraClient and FedoraAPIM methods. After > a thousand iterations the average time it took to upload a 10Mb file was > about 500 msec. Than adding this file to a digital object with FedoraAPIM > addDatastream method took on average nearly a second. Mind that in this > sequence of operations the file is moved two times (if I'm not missing out > anything): from the original location to the temporary 'uploaded' and from > there to its final destination as managed content in the repository. Looks > like when we cut out the upload-operation we might gain an improvement of > 33% on speed of file ingestion. > > If urls with the file:///-protocol were allowed in the addDatastream method > than ingesting data from mounted Tera-byte discs would become significantly > faster. So sure, 'Allow the retrieval of content via the file URI scheme' ( > https://fedora-commons.org/jira/browse/FCREPO-453) has my full support. > > greetings, > henk van den berg, > software developer at DANS - Data Archives and Networked Services > http://www.dans.knaw.nl > > > On 28-05-09 17:01, "Benjamin Armintor" <[email protected]> wrote: > > > There are some open issues related to your problem: > > https://fedora-commons.org/jira/browse/FCREPO-453 > > https://fedora-commons.org/jira/browse/FCREPO-485 > > > > If you have an account on the issue tracker, please vote for them! > > > > With regard to your questions: > >> Is there a legal way to let Fedora read managed content from disc? (other > >> than the one described above) > > > > I don't believe there's an out-of-the-box way to specify file:// URLs > > (at least, there wasn't last time I looked at the release code). You > > could probably sort out a way to copy your files into the temp > > directory and provide the uploaded:// urls yourself, but that seems > > like a frail solution. > > > >> Is this ValidationUtility class out of sync with the rest of the code body? > >> Does it accidentally prevent something that elsewhere is legal routine? > >> And if so, when is it going to be repaired? > > > > The temp and uploaded protocols are supposed to be internal, and the > > ValidationUtility is supposed to deal with externally supplied > > content. In that sense, things aren't broken, but the aforementioned > > issues reflect a desire for this to change. > > > >> Are there any reasons why not to use the hacked ValidationUtility class > >> (besides from being a hack); will using it corrupt something somewhere > >> else? > > > > Once your objects/updates are ingested, Fedora will be tracking the > > location of the managed content internally, so you should be safe. > > > > Regards, > > Benjamin > > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Fedora-commons-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
