Hi Ben, I wasn't specifically thinking of ExternalContentManager when I wrote that, but it does seems like it'd be a logical starting point.
Regardless of how it's done, it'd be good have file:/// support as an option that people can use for ingests. To include it in the baseline, we'd need to at least have a simple way for repo admins to prevent people for sending in file:/// urls they don't want to permit, such as file:///etc/passwd I don't think that making it pluggable is a necessity...just a nice-to-have. If the implementation of FCREPO-453 turns out not to be pluggable, then having a separate feature request for making it so would be good. - Chris On Fri, Mar 13, 2009 at 12:48 PM, Benjamin Armintor <[email protected]> wrote: > Chris, > > I think I misread this comment as a suggestion to think of this in > the existing pluggable infrastructure, where it nearly fits. Are you > suggesting an entirely new Module interface? I don't criticize the > suggestion (and it makes sense given the various places that a service > or module tries to fetch a datastream), but it does deflate my hopes > of seeing this feature find it's way into a relatively near-term > release a bit. > > Should I submit an entirely new issue? > > - Ben > > On Fri, Mar 6, 2009 at 5:19 PM, Benjamin Armintor <[email protected]> wrote: > >>> I think it's definitely in the spirit to allow content to come in via other >>> "protocols" here. Making it pluggable would be great. Some kind of >>> "URI content resolver" interface would seem to be in order. >>> >>> - Chris ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
