Quoting [Thilo Kielmann] (Jun 02 2009):
So, what are we doing with this [mtime problem]? Can we still smuggle this into the "errata" thingy???
Well, I did not send around notes from OGF26, yet, so let me fix this right now. Apart from the usual stuff, there have been two major discussion points: - In the sessions, we discussed approaches to a workflow package. The general feeling (between the 4 active participants :-P) has been that task dependencies are an excellent entry point. Branching and looping should also be rendered as special task types. Outside the session we got good input to the topic as well, and a number of external pointers: Legion, Unicore (AJO) and iRods all are good references, and are closer to our scheme of things than I would have thought. We are actually already implementing something like this in C++, so you can expect an explicit proposal soonish. If anybody is interested in an earlier discussion, on the list or by phone, please let me know. - The GFSG discussed our errata procedure. It was agreed that the errata are well motivated (because mostly triggered by implementation work) and mostly backward compatible (there are two items which are not, but all implementations have them implemented the same way I think). However, GFSG wants to motivate us to finally produce our experience document for GFD.90, to get the Core API from 'proposed recommendation' state into full 'recommendation' state. It was thus proposed to delay the errata until that experimental document has been handed in, and treat the errata as accomanying spec update. It makes sense I guess, even if I don't like the delay myself. Anyway, I started to work on the experimental document, and will approach the individual implementation groups for input over the next weeks. Lets try to get it out by next OGF. So, on the up side, we are still able to fiddle around with the errata for a while, and should try hard to use that time to get our implementations in sync. To answer Thilos question: I think mtime should go into errata, no matter what way we decide to solve it. Semantically, it is a small change, and it is already imlemented in JSAGA - which makes it an errata IMHO. The typed attributes should *not* be part of the errata, but rather go either into an extension package, or into v2.0, IMHO. It was a conscious decision to go for strings in v1.0, so now saying we need to 'fix' it makes not much sense. Maybe I shouldn't have brought it into the mtime thread, sorry for mixing up issues here... Best, Andre. -- Nothing is ever easy.