On 12/16/05, Mike Sparr - www.goomzee.com <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
