commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [SCXML] SCXMLDigester setNamespaceAware
Date Sat, 17 Dec 2005 18:18:56 GMT
On 12/16/05, Mike Sparr - www.goomzee.com <mike@goomzee.com> wrote:
> Rahul,
>
> No, just namespace URIs (I'll confirm Sunday night), but as we
> constructed SOAP-ENV message within send tags, our web service wouldn't
> accept the format of the message.  After turning off setNamespaceAware
> (set to false), it worked?  We can either send via encoded URI (REST) or
> merely add the SOAP env and pass it on - very cool!
>
<snip/>
>
> Below is example of output to client (transform is determined by which
> plug-in they access, usually a servlet but can be IM Gateway, SMS
> Gateway,  etc., just implementing our plug-in Interface)...
>
<snip-example/>
>
> We transform
> vxml response depending on client (rich text, vxml, text, html, etc.).
> It's built to be very flexible, we can even interact with REST WS or any
> encoded URI access to an app via <var> and namelist along with URI as
> target.  I'm not sure about performance of the whole thing - may add LRU
> Cache - but it does what I wanted it to and qualifies as an end-to-end
> SCXML/VXML MMI Framework w/ single plug-in architecture for n Clients.
> :-)  Probably first in the world I imagine!  :-O  Anyone need a bot
> built, in minutes?
>
<snap/>

Super! You've demonstrated what some of us have merely claimed to be
the advantages obtained by using Commons SCXML in web-based
applications:

 * Separation of "dialog flow" from "views"

 * The multiple channels and devices aspect (catering markup to device
and modality used by end user)

 * Event triggered messages sent to external components (servlets,
web-services calls, SOAP over HTTP, what have you)

This is great stuff, Mike :-)


> Given digester is Open, a knowing (or unknowing like myself) individual
> can theoretically customize as they see fit.  As such, perhaps just
> leave it alone or implement the solution you mention.
>
<snip/>

I see the theory, makes sense to give the SCXMLDigester class a
Factory flavor. I'll add this to my TODO list for the weekend, will
probably get to it tomorrow.


> As a final note, if you have any input to W3C spec, I suggest removing
> mutual exclusivity of either namelist vars OR send body contents.  I
> believe they are supposed to throw fetch.error or something.  Commons
> SCXML does not, but as I stated before, I think this is best as it's
> nice to  access to some vars in context that may not necessarily be used
> for messages, etc.
>
<snap/>

As far as feedback is concerned, the W3C based on my understanding and
experience (arguably, limited experience), is open to suggestions from
everyone. There are public mailing lists -- to which anyone can
subscribe, just like the lists here at Apache -- and offer feedback. I
would recommend you post any suggestions about the specification
itself on the Voice Browser Working Group's (the SCXML spec is
currently a Working Draft out of the VBWG) public mailing list.


> Cheers,
>
>
> Mike
>
> P.S. - where do you work? And are you in US?
>
<snip/>

I'm in the big apple, where the big blue keeps me busy during the day.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message