[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] new rm prototype
|
Greg,
I've now taken a look. I like the setup generally and I think it will work fine.
One thing we might want to add, however, is an interface + abstract implementation for the actual job state update provider. The reason I think this might be handy is that in the case of most DRMS, polling will be necessary, and that will basically look the same except for the specifics of the command (this could be implemented on either side, client or server). Also, the state mapping and the matching and updating against those data structures could also be abstracted away, as this will undoubtedly be shared functionality, either for a polling or an asynchronous version. I think this can be as lightweight as possible, but there would not be any need to replicate it for every RM. We would just provide the RM interface with either a factory method for this sub-component.
stdout/stderr needs more thought, though perhaps a high-level listener abstraction would do for the moment.
Do we need to abstract out the batch/interactive switch (it was my impression we were going with the idea that a single RM implementation should be able to handle one or both modes)?
After tomorrow's call I'd be happy to move forward with any and all agreed upon additions or modifications.
Al
