Hi Ray, Overall this is an excellent write-up that captures all of what I had heard about policies in our sessions and takes it into implications in the middleware architecture. A couple brief comments:
I assume we are not taking the word "File" in Policy File literally as a file in a file system, we probably want to store policies and parameters in a database so we can cross-reference and query against it, and generate an XML version for use during execution. Conversely, we probably want to edit Policies as XML files and suck them into the database. I would do a pass back over your text and make sure you didn't use Policy File where Policy would suffice (e.g. The last paragraph of 3.3.1 probably could say Policy rather than Policy File). As I understand the write-up, the Policy's role in terms of output parameters is purely to create the definition of them, and that the actual copying of the resulting values is in other parts of the middleware framework (i.e. Processing Step glue code). That is, I assume we will not have the a "copy output" operation on the Policy object. Otherwise, unless there are other objections, we can incorporate this into the model. Jeff > From: Ray Plante <[EMAIL PROTECTED]> > Reply-To: Ray Plante <[EMAIL PROTECTED]>, LSST Data Management > <[email protected]> > Date: Mon, 13 Mar 2006 17:21:45 -0600 (CST) > To: LSST Data Management <[email protected]> > Subject: [LSST-data] Policy Objects [MiddleWG][DataAccWG] > > Keywords: MiddleWG, DataAccWG > > Hi MWGers and DAWGers, > > As promised, attached is a document discussing the Policy and related > classes (also in docushare as Document-1397). It contains all I've > gleaned from the UML Model and the LSST WCS Prototype Pipeline and expands > on it to clarify its interactions with 3 of our high-level components > (PCS, DAF, and PE). For example, I want to explore modeling data staging > strategies as Policy objects. Pending feedback from the working groups, I > plan to fold these ideas back into the UML model. > > So the main purpose for sharing this document is to make sure my thinking > about Policies is consistant with others (particularly those that created > the concept and have been prototyping it). > > We discussed Policies last week in the DataAccWG telecon, and one of the > concerns brought up was about adjusting parameters at run-time. In > particular, the MiddleWG talked about (at the Middleware-Apps > interface video-con meeting) having the ability for one Component to > subscribe to an event from another Component up- or down-stream in a > pipeline, and that the Component would as a result of receiving an event > change its behavior. This brought up some concerns about when the change > takes effect and how that would be captured in the Provenance such that > any data products could be reproduced. This document tries to collect > those issues and ramifications. So, do we really need this feature? > If so, did I capture the right approach for handling this? > > Your comments would be appreciated. > > cheers, > Ray > > > _______________________________________________ > LSST-data mailing list > [email protected] > http://www.lsstmail.org/mailman/listinfo/lsst-data > _______________________________________________ LSST-data mailing list [email protected] http://www.lsstmail.org/mailman/listinfo/lsst-data
