General

I've found the table that stores file information: mdas_ad_repl

MCAT can be set up to run a function when an INSERT, UPDATE or DELETE call is made on the table.

the function can be writen in a number of languages, including C and Python.

I've written a basic python test function that prints out the 'Trigger Data' dict object to a file.

Now when I do an Sput, Smv, etc the file gets appended with the data from that event.

Interestingly, when Sput is used, no matter how large the file, three events are triggered. an INSERT, which creates the entry for the new file, with a listed datasize of 0. then when the file is finished two UPDATE events are created. The first UPDATE seems to just update the file size to the correct file size. where the second UPDATE changes an attribute called 'is_dirty' to 2. The only description of this 'is_dirty' attribute is:

IS_DIRTY                      /* data has been changed in the container
					compared to other copies  */

which isn't very descriptive. I'm going to get on the SRB mailing list and fire off a question about this. But for now it looks like this could be the answer to telling when a file has finished uploading to the SRB.

Of course the issues Ian brought up still need to be addressed:

Weather the MCAT schema is stable, since changes to the database schema could break the triggers.

And what the deal is with using multiple MCAT servers. A test system might have to be set up to play with this

Why do we need to implement a trigger system in SRB when most databases (i.e. oracle and postgresql) used for the MCAT support triggers?

I'm pretty sure that file information is stored in the MCAT so we should be able to build triggers to preform operation (i.e. execute kepler workflows, send SOAP packets to an axis server which can be queried by kepler)

This should remove the need for the SRB directory poller system.

I've been playing around with the Software section on Plone and adding my Kepler actors as software packages (eg. Kepler SRB Actors). I've been pondering over what should be put up there. I've come to the conclusion that i'll just put usage documentation into Plone and leave all the implementation details to the javadocs.

If there was a simple way to embed javadocs into plone this would be fine, but it isn't very efficient to have 2 different sets of documents for the one thing.

I've begun creating some documentation by moving and cleaning up some of the documentation style blog entries. If you can think of any other topics that you would like to see documented add a comment to this entry.