On 6/23/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
I wish I had found time to play with SCXML previously - what you've done looks good Rahul.
<snip/> Thanks for your time and the feedback.
1) What is the status of the SCXML specification? The docs currently mention the working draft from July 2005 - but the latest on the web site is January 2006. I'm wondering how much change (if any) there is likely to be between the current working draft and the (presumably) 1.0 version of the spec. Maybe it would be better to release SCXML with a different version number (e.g. 0.8 or WD2 etc) and save the 1.0 version for when the spec is final and put health warnings that the API may change depending on the final specification.
<snap/> This is a valid point. For me, a version number is simply a number and the thought of synchronizing 1.0 until the spec is effectively out hadn't crossed my mind (we'd just have hit 2.0 then). However, I think that the above probably makes more sense. IMO, its better to have a number (say, 0.8) rather than WD2, for example. I also like the idea of putting "health warnings" (for example, the <datamodel> section and the <invoke> section might see some changes). That leads me to the following questions: (a) What version number should be used? 0.8? (0.5? -- per betwixt). I'm fine with either. (b) Where should the warnings go? (I was thinking of a stability page in the docs, and a mention of that page in the release notes) (c) I am planning on changing the version accordingly for all tags and branches as well (to avoid confusion down the road). Any objections? (d) Say we pick 0.8, should the next RC be 0.8-RC1 or 0.8-RC2?
2) I'm not an expert in listeners/events - but typically listeners extend the java.util.EventListener tagging interface and events extend java.util.EventObject. Also the operations of a listener typically take an event object which SCXML doesn't seem to follow. Wouldn't it be better to follow this pattern for SCXML?
<snip/> Unfortunately, the concept of "event" becomes somewhat overloaded in the realm of state machines, and might get confused with UI or model centric events with event "sources". In state chart theory, there is no concept of external events having any event source. Similarly, the SCXMLListener is a provided convenience for watching state entries, exits and transitions (within a state machine), rathering than listening to any "events" (though it may be possible to think of an entry as a onentry event by squinting at it a bit). In short, I'm afraid whether any attempts to align with the j.u package might be artifical, rather than conceptual.
3) My instinct would have been to avoid dependencies on the servlet/JSF api and to keep SCXML more tightly focused on its primary aim. I realize you're trying to facilitate usage from these technologies by providing the context implementations but since these are minor wouldn't it be better to just document how-to for these and keep SCXML dependencies to a minimum. Maybe having these dependencies will make it tempting to provide further technology dependant features in the future - blurring the scope of the component.
<snap/> Those are runtime dependencies in Maven "provided" scope (fairly obvious), but let me clarify further. Based on my experience so far with Commons SCXML, we need to provide the (often trivial) impls to facilitate adoption. Its understandbly hard to expect folks to run with something that doesn't provide any conveniences out of the box. None of the usecases I've seen on the mailing lists plugged in a new EL (which is basically what would be required if we didn't provide any). The focus of the o.a.c.scxml.env.* packages is simple, generic stuff for a limited number of technologies (as an example, I removed the Shale related Evaluator before RC1, which IMO was too specific). I have previously pushed back on adding any heavier stuff there, and I'm just as keen about not jeopardizing the scope (beyond what is apparently absolutely essential).
4) In the user guide "Hello World with a custom action" - link is invalid (points to "custom-hello-world.xml" but should be either "custom-hello-world-01-.xml" or "custom-hello-world-02-.xml") 5) In the "SCXML Digster" part of the user guide it would be better IMO to point to the javadoc for the "model" package, rather than the subversion repository.
<snip/> Thanks for spotting 4 and 5 above. I'm traveling, so left to me, they will have to wait for a bit though. -Rahul
Niall On 6/20/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > Release Candidate 1 for Commons SCXML 1.0 is available for review: > > http://people.apache.org/~rahul/commons/scxml/dist/ > > New version of the Commons SCXML site: > > http://people.apache.org/~rahul/commons/scxml/ > > This is the first release, release notes are bland: > > http://people.apache.org/~rahul/commons/scxml/RELEASE-NOTES.txt > > More details are in the changes report: > > http://people.apache.org/~rahul/commons/scxml/changes-report.html > > My key is here, amongst other places: > > http://people.apache.org/~rahul/rahul.asc > > All feedback on this release candidate is welcome. As an aside, I will > be away for three weeks, and my replies will be very slow during that > time. > > -Rahul
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
