Re: [scxml] update and progress?
On 2015-12-04 16:21, R.C. Hoekstra wrote: Hi Ate, thanks for answering. As for the datamodel... Well, I put the stuff in our project which depended on the datamodel on hold. We wanted to apply a datamodel in order to separate the state flow logic and the numbers used in it, but we haven't done that up to now, because I was afraid that the datamodel on scxml commons would become subject of serious changes. So for us it's still very flexible, as we didn't start with that part yet. I have a slight personal preference for at least the xml in the datamodel, but it's not that important. For us the progress of the project is much more important than the choice on which language support will be there and which not. So I can perfectly live with JSON. And if your proposal leads to greater ease of use and faster implementation, that is fantastic. Please do so. The support for java8 is also fine with me. We're doing everything in java 8. So conclusion: your proposal is supported from over here! Thanks Rinke, that is very helpful feedback! I'll come up with a concrete (lazy consensus) proposal on the *dev* list for: - dropping XML/XPath support - adding JSON datamodel support - requiring Java8 and then take it from there with an updated plan. Regards, Ate best regards, Rinke Hi Rinke, On 2015-11-24 12:24, R.C. Hoekstra wrote: Hi Ate, Woonsan, I was wondering if you guys could give us an update on the progress of SCXML, and tell us how it's going. Specifically, I was wondering if you could give us any clue on when Milestone 2 can be expected. I'm looking forward to the new datamodel features with great interest. I don't see much questions and activity on the mailinglist on scxml, but I'd like you to know that we are still very enthousiastic on the scxml project. That is great to hear, and thank you for saying so! Obviously there hasn't been much progress since early this year :( Main reason for this is that the current M1 release has been sufficient for our current use-cases, so far, and we thus right now don't have a real business driver nor concrete budget/time to work on this during working hours, regrettably. That doesn't mean I (and Woonsan) are no longer interested in working on this, but can only do so on our own account outside office hours. And as we've been very busy with lots of other work, you probably can understand that working on Commons SCXML kind of ended up on the back burner. Also there hasn't been much input from the 'community' either... That said, your question tricked me in reviewing again the current state and outstanding issues, for M2 and beyond, and what can/should be done next. And I now realize again that another reason why I 'dropped the ball' since last February is that at that time I reached several technical and frustrating problems in the current functionality, concerning both the Javascript and XPath datamodel support. As you might know, the now final SCXML 1.0 specification at the end dropped the XPath support because there were no concrete implementations, because of lack of interest and too many complications and limitations with XPath to be able to provide a proper implementation. And those same complications and limitations are also causing serious and invasive problems in the (overall) implementation in Commons SCXML. Honestly, I'm fed up with the XML/XPath datamodel as it is hampering and complicating the implementation way too much. Therefore, I want to propose to completely drop XML/XPath datamodel and language support for Commons SCXML 2.0, before moving on with completing and wrapping up the goals for M2. This however is a very radical change, including dropping the support for the Data() and just added Location() functions for the Jexl and Groovy languages. Instead however, I would like to replace this by providing proper JSON datamodel support, not just for Javascript but also the Jexl and Groovy languages. Technically and functionally this will be: - much easier and straightforward to implement with a lot less edge-cases - much easier and practical to use And in addition, for proper Javascript support we should move to Java 8 (Nashorn Javascript engine), and thus drop support for Java 6 and 7. But before doing so, this needs to be discussed and agreed upon by the Commons SCXML community, however small a group that might be nowadays. I hope you and others can comment on this idea and provide feedback if you would be OK, or why not. If for example you or others strongly depend and rely on XML datamodel support, than this might be a no go, unless you are fine with migrating from XML/XPath to JSON instead. If we can make this decision: drop XML/XPath support, add JSON as alterative, and move to Java 8 as minimum, then we can move forward much faster and with a much cleaner and leaner implementation. I'd then be happy and motivated again to continue working towards M2 shortly, and I know Woonsan is willing to pitch in then as wel
Re: Re: [scxml] update and progress?
Hi Ate, thanks for answering. As for the datamodel... Well, I put the stuff in our project which depended on the datamodel on hold. We wanted to apply a datamodel in order to separate the state flow logic and the numbers used in it, but we haven't done that up to now, because I was afraid that the datamodel on scxml commons would become subject of serious changes. So for us it's still very flexible, as we didn't start with that part yet. I have a slight personal preference for at least the xml in the datamodel, but it's not that important. For us the progress of the project is much more important than the choice on which language support will be there and which not. So I can perfectly live with JSON. And if your proposal leads to greater ease of use and faster implementation, that is fantastic. Please do so. The support for java8 is also fine with me. We're doing everything in java 8. So conclusion: your proposal is supported from over here! best regards, Rinke Hi Rinke, On 2015-11-24 12:24, R.C. Hoekstra wrote: > Hi Ate, Woonsan, > > I was wondering if you guys could give us an update on the progress of > SCXML, and tell us how it's going. > > Specifically, I was wondering if you could give us any clue on when > Milestone 2 can be expected. I'm looking forward to the new datamodel > features with great interest. > > I don't see much questions and activity on the mailinglist on scxml, but I'd > like you to know that we are still very enthousiastic on the scxml project. That is great to hear, and thank you for saying so! Obviously there hasn't been much progress since early this year :( Main reason for this is that the current M1 release has been sufficient for our current use-cases, so far, and we thus right now don't have a real business driver nor concrete budget/time to work on this during working hours, regrettably. That doesn't mean I (and Woonsan) are no longer interested in working on this, but can only do so on our own account outside office hours. And as we've been very busy with lots of other work, you probably can understand that working on Commons SCXML kind of ended up on the back burner. Also there hasn't been much input from the 'community' either... That said, your question tricked me in reviewing again the current state and outstanding issues, for M2 and beyond, and what can/should be done next. And I now realize again that another reason why I 'dropped the ball' since last February is that at that time I reached several technical and frustrating problems in the current functionality, concerning both the Javascript and XPath datamodel support. As you might know, the now final SCXML 1.0 specification at the end dropped the XPath support because there were no concrete implementations, because of lack of interest and too many complications and limitations with XPath to be able to provide a proper implementation. And those same complications and limitations are also causing serious and invasive problems in the (overall) implementation in Commons SCXML. Honestly, I'm fed up with the XML/XPath datamodel as it is hampering and complicating the implementation way too much. Therefore, I want to propose to completely drop XML/XPath datamodel and language support for Commons SCXML 2.0, before moving on with completing and wrapping up the goals for M2. This however is a very radical change, including dropping the support for the Data() and just added Location() functions for the Jexl and Groovy languages. Instead however, I would like to replace this by providing proper JSON datamodel support, not just for Javascript but also the Jexl and Groovy languages. Technically and functionally this will be: - much easier and straightforward to implement with a lot less edge-cases - much easier and practical to use And in addition, for proper Javascript support we should move to Java 8 (Nashorn Javascript engine), and thus drop support for Java 6 and 7. But before doing so, this needs to be discussed and agreed upon by the Commons SCXML community, however small a group that might be nowadays. I hope you and others can comment on this idea and provide feedback if you would be OK, or why not. If for example you or others strongly depend and rely on XML datamodel support, than this might be a no go, unless you are fine with migrating from XML/XPath to JSON instead. If we can make this decision: drop XML/XPath support, add JSON as alterative, and move to Java 8 as minimum, then we can move forward much faster and with a much cleaner and leaner implementation. I'd then be happy and motivated again to continue working towards M2 shortly, and I know Woonsan is willing to pitch in then as well. That might still need a few months work to complete, but definitely overseeable. Kind regards, Ate - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.
Re: [scxml] update and progress?
Hi Rinke, On 2015-11-24 12:24, R.C. Hoekstra wrote: Hi Ate, Woonsan, I was wondering if you guys could give us an update on the progress of SCXML, and tell us how it's going. Specifically, I was wondering if you could give us any clue on when Milestone 2 can be expected. I'm looking forward to the new datamodel features with great interest. I don't see much questions and activity on the mailinglist on scxml, but I'd like you to know that we are still very enthousiastic on the scxml project. That is great to hear, and thank you for saying so! Obviously there hasn't been much progress since early this year :( Main reason for this is that the current M1 release has been sufficient for our current use-cases, so far, and we thus right now don't have a real business driver nor concrete budget/time to work on this during working hours, regrettably. That doesn't mean I (and Woonsan) are no longer interested in working on this, but can only do so on our own account outside office hours. And as we've been very busy with lots of other work, you probably can understand that working on Commons SCXML kind of ended up on the back burner. Also there hasn't been much input from the 'community' either... That said, your question tricked me in reviewing again the current state and outstanding issues, for M2 and beyond, and what can/should be done next. And I now realize again that another reason why I 'dropped the ball' since last February is that at that time I reached several technical and frustrating problems in the current functionality, concerning both the Javascript and XPath datamodel support. As you might know, the now final SCXML 1.0 specification at the end dropped the XPath support because there were no concrete implementations, because of lack of interest and too many complications and limitations with XPath to be able to provide a proper implementation. And those same complications and limitations are also causing serious and invasive problems in the (overall) implementation in Commons SCXML. Honestly, I'm fed up with the XML/XPath datamodel as it is hampering and complicating the implementation way too much. Therefore, I want to propose to completely drop XML/XPath datamodel and language support for Commons SCXML 2.0, before moving on with completing and wrapping up the goals for M2. This however is a very radical change, including dropping the support for the Data() and just added Location() functions for the Jexl and Groovy languages. Instead however, I would like to replace this by providing proper JSON datamodel support, not just for Javascript but also the Jexl and Groovy languages. Technically and functionally this will be: - much easier and straightforward to implement with a lot less edge-cases - much easier and practical to use And in addition, for proper Javascript support we should move to Java 8 (Nashorn Javascript engine), and thus drop support for Java 6 and 7. But before doing so, this needs to be discussed and agreed upon by the Commons SCXML community, however small a group that might be nowadays. I hope you and others can comment on this idea and provide feedback if you would be OK, or why not. If for example you or others strongly depend and rely on XML datamodel support, than this might be a no go, unless you are fine with migrating from XML/XPath to JSON instead. If we can make this decision: drop XML/XPath support, add JSON as alterative, and move to Java 8 as minimum, then we can move forward much faster and with a much cleaner and leaner implementation. I'd then be happy and motivated again to continue working towards M2 shortly, and I know Woonsan is willing to pitch in then as well. That might still need a few months work to complete, but definitely overseeable. Kind regards, Ate best regards, Rinke - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[scxml] update and progress?
Hi Ate, Woonsan, I was wondering if you guys could give us an update on the progress of SCXML, and tell us how it's going. Specifically, I was wondering if you could give us any clue on when Milestone 2 can be expected. I'm looking forward to the new datamodel features with great interest. I don't see much questions and activity on the mailinglist on scxml, but I'd like you to know that we are still very enthousiastic on the scxml project. best regards, Rinke - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
