You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rahul Akolkar <ra...@gmail.com> on 2006/06/20 20:25:36 UTC
[all][scxml] Version 1.0 RC 1 available
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all][scxml] Version 1.0 RC 1 available
Posted by Rahul Akolkar <ra...@gmail.com>.
On 6/23/06, Niall Pemberton <ni...@gmail.com> 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 <ra...@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all][scxml] Version 1.0 RC 1 available
Posted by Niall Pemberton <ni...@gmail.com>.
I wish I had found time to play with SCXML previously - what you've
done looks good Rahul.
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.
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?
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.
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.
Niall
On 6/20/06, Rahul Akolkar <ra...@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org