Hi Chris, As mentioned on irc, I think having both of these (notification for read-oriented API calls, and relationship-level change notification) would be good, but I want to see what other people think too. Some thoughts:
For notification of read-oriented calls, it'd be nice to have a way to turn on/off either API-A or API-M oriented messages across the board. Admins may be only interested in paying the performance price of one or the other. For notification of relationship-level (err.. statement-level) changes, currently apps can subscribe to the appropriate RELS-* changes, but as you point out, determining the diffs is difficult because you have to look at the previous revision, and if it's a purge operation, that's not available. Implementation-wise, there is already an area in the code where the triple differences between one rev and the other (of a Fedora object in general) are known: the resource index update code. See updateTripleDiffs in http://fedora-commons.svn.sourceforge.net/viewvc/fedora-commons/fedora/trunk/server/src/main/java/fedora/server/resourceIndex/ResourceIndexImpl.java?revision=8082&view=markup Although this problem (communicating diffs) is general and not restricted to RDF, I think it's fair for the Fedora repository to be format-aware in this case because we've already acknowledged RELS-* as special citizens of the core repository. - Chris On Tue, Jul 28, 2009 at 6:09 PM, Chris Beer<chris_b...@wgbh.org> wrote: > Following up on Mike Park's messaging thread, I'd like to also suggest the > addition of relationship-level notifications (in addition to the API-M level > messages). > > The drawback of API-M messages is capturing updates to the RELS-EXT/INT when > they are modified by modifiyDatastream rather than the add/purgeRelationship > methods. In some circumstances, it isn't even possible to reconstruct > (through set operations or otherwise) what changes took place (as when the > versioning is disabled). > > At the most basic level, this could support (or, at least simplify) > maintaining external triplestores or similar. It seems like this isn't too > difficult given the current setup, but probably results in additional mass > purge + recreate operations. > > My immediate use case is domain-specific implications for specific > relationships (like collection membership, content model assertions, or even > state-based triples) that could trigger workflow processes (whenever an > object is added to collection X, notify A; whenever an object asserts it is > an archival video, start an encoding process to create a new proxy copy; etc) > . > > Thoughts? To me, it seems a little too different than API-based messages to > be an easy addition, but it also seems like it'd really help streamline some > applications, especially as more people start developing workflow processes > around Fedora. > > Thanks, > Chris Beer > Web Developer > WGBH Interactive > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Fedora-commons-developers mailing list > Fedora-commons-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
