Chris, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Chris > Wilper > Sent: Tuesday, February 24, 2009 1:02 PM > To: Strnad, Kai > Cc: FC Developers List > Subject: Re: [Fedora-commons-developers] Performance wiki and Managed > Content > > On Tue, Feb 24, 2009 at 2:40 AM, Strnad, Kai > <[email protected]> wrote: > > natural way to obtain files residing on the same machine. Perhaps we > could > > introduce two parameters for this: one that acts as a switch and > generally > > turns file URLs on/off and a second that defines a set of allowed > file URLs > > with optional recursion ? >
Yes if the mechanism has to be deactivated temporarily without losing the configured URLs the switch/set alternative may be the way to go. A less strict and simpler way is to just have one switch and generally allow any (sanitized) file URI. > I could see it working well with either an on/off switch or just > telling people > they need to "comment out" the list of allowed URLs if they want to > disable > it altogether. > > On the recursion idea, I guess I was assuming it would always be > recursive. > But you're thinking that sometimes people would want to only allow > ingesting > content in, /path/to/files/, but not /path/to/files/subdir/, right? > Right, but on second thoughts I guess the optional recursion is likely to make things overly complicated. So maybe it's better to stick with "always recursive". > > A related idea could be to use a virtual file system provider like > Apache > > VFS. This could further simplify the retrieval of managed content by > > abstracting the access to multiple file systems and protocols. There > are of > > course even more possible security implications with this approach > and I > > also don't know about the stability and the impact on ingest > performance. > > Something like VFS would open up some interesting possibilities. > I took a quick look at VFS and saw that it has a core dependency > (for URI parsing) on an older version (2.0) of commons-httpclient than > Fedora > requires (3.1). As I recall, there were some significant API changes > between > these commons-httpclient releases, so it may be difficult to use VFS > as-is > without resorting to classloader magic. Still worth a deeper look, > though. > This could be a problem. I will take a more thorough look at it and see what needs to be done in order make it work with Fedora and also see what benefits and drawbacks the VFS approach could have... I've just created a tracker item for the issue (https://fedora-commons.org/jira/browse/FCREPO-453). - Kai > - Chris ------------------------------------------------------- Fachinformationszentrum Karlsruhe, Gesellschaft für wissenschaftlich-technische Information mbH. Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB 101892. Geschäftsführerin: Sabine Brünger-Weilandt. Vorsitzender des Aufsichtsrats: MinR Hermann Riehl. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
