I wonder if this might be a good direction to extend the Fedora messaging services? By default, the embedded activemq broker bundles with Fedora sends messages, but does not set up a listener to receive them; this could be modified, however, and Fedora could be wired up to do something like monitor a filesystem or URL, and receive an update notification when an external resource changes, which it could then act upon to refersh its cache, recalculate datastream sizes and md5sums, etc.
Of course, for looser coupling, this could just as easily been done with a message processing service/enterprise service bus outside of Fedora, in which case the outside service would be responsible for sending updates, deletes to Fedora via the usual API-M functions. That might be preferable, especially as you'd want to account for outages of the remote resource, other factors that make pointing to external resources fragile. -- Scott On 05/12/2011 07:28 AM, aj...@virginia.edu wrote: > There is a general point here about external datastreams: Fedora has no way > to know when they change. To my knowledge, it does not poll those URLs or > maintain timestamping on them or the like. In a situation where Fedora is > caching information derived from external datastreams (or some other part of > a system is caching information derived from Fedora external datastreams) > there is no immediate way to have changes propagate as appropriate without > adding additional machinery. Fedora can't do it by itself. > > --- > A. Soroka > Online Library Environment > the University of Virginia Library > > > > > On May 12, 2011, at 7:22 AM, Swithun Crowe wrote: > >> I was expecting external FESLPOLICY datastreams to be refreshed when the >> external version was updated. But what I should expect is that datastreams >> get refreshed if the local copy is modified (managed), or the datastream >> changes state (managed/external). > > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Fedora-commons-users mailing list > Fedora-commons-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users -- Scott Prater Library, Instructional, and Research Applications (LIRA) Division of Information Technology (DoIT) University of Wisconsin - Madison pra...@wisc.edu ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
