Spray (kudos)

Steve,

I have downloaded Spray today, and after a few hours I was able to hack a
piece of code that calculates rank of the url in google for particular
search string. Given that I have never been programming with SOAP before, I
must say you have done a great job in providing such easy to use and
comprehensive library. Thanks!

Now a few questions :) . Is it possible to (automatically) wrap remote calls
into some nice selectors? For instance if remote operation is logically
something like:

opName(par1, info, moreInfo)

to have a soap client that is able to understand message:

#opName:info:moreInfo:

(this is the way CORBA operations get mapped).

Second question is if there is some formal or informal standardization for
smalltalk mapping to the SOAP. In other words, if I develop client app with
Spray, what is the likehood that the same app will work on VW or something
else? Is there maybe some process on the CampSmalltalk?

Third question is what is the motivation for using SAXO and Simple
HTTPClient? Are they more efficient than MS implementation, or they have
more suitable interface or something else?

Thanks,

rush

Hi rush,

> I have downloaded Spray today, and after a few hours
> I was able to hack a piece of code that calculates rank
> of the url in google for particular search string. Given
> that I have never been programming with SOAP before,
> I must say you have done a great job in providing such
> easy to use and comprehensive library. Thanks!

Thanks, that is good to hear.

> Now a few questions :) . Is it possible to (automatically) wrap remote
calls
I played around with generating client proxy classes, but never went on with
it. You could use the SprayDispatchClient class, which implements
#doesNotUnderstand: in such a way that sending the #opName:info:moreInfo:
message to it, will send opName(par1, info, moreInfo). The
SprayDispatchClient class has an example which should get you started.

A digression; The main reason I didnt keep working on generating client
proxy classes is because I ended up questioning whether a network operation
should be treated as a normal message send. A pattern that worked better for
me, was to queue the SOAP sends (returning immediately), and treate the
arrival of the SOAP response like an event being triggered. The Currency and
Terra client examples use this technique, and I found it a more natural fit
with Dolphin's MVP framework.


> Second question is if there is some formal or informal
> standardization for smalltalk mapping to the SOAP.
> In other words, if I develop client app with Spray, what
> is the likehood that the same app will work on VW or
> something else? Is there maybe some process on the
> CampSmalltalk?

The CampSmalltalk work was to have a standard way of describing a type for a
class, and (from a webservices point of view) mapping those types to
XMLSchema and WSDL descriptions. This would allow you to take a smalltalk
model and deploy it as a service in either Spray, VA or VW. I have it
working (with an example service), but have not released the code as yet. If
you are interested, let me know and I will dig it out.

There was no work done on standardizing the clients. I would imagine the
difficulty with this would be what exceptions are signalled, and what the
user can do if the send doesnt work as expected. Is this standardized for
CORBA across the Smalltalk dialects?

> Third question is what is the motivation for using SAXO
> and Simple HTTPClient? Are they more efficient than MS
> implementation, or they have more suitable interface or
> something else?

The motivation was they are Smalltalk :)

FWIW: You can use MSXML2.6 or MSXML 3.0 instead of YAXO by installing the
packages in "Spray WebServices\Spray\Parsers" folder. (The package comments
explain how to change the environment to enable those parsers).

Similarly, in the "Spray WebServices\Spray\Transport" folder, the packages
"SW SPT MSXML" and "SW SPT MSXMLv3" will allow you to use either the
IXMLHTTPRequest or IServerXMLHTTPRequest interfaces in place of the Simple
HTTPClient.

As for my motivation, the first release of Spray used MSXML for both the
parser and http transport. I ended up getting frustrated at not being able
to track down or fix bugs. While some of those bugs turned out to be mine,
the older versions of MSXML do contain bugs. In addition I found that
deploying applications that depend on the MSXML control was a major source
of problems.

Lastly, I have done alot of work with HTTP and WebDAV recently, which I
probably wouldnt have done if I hadnt made the start with the Simple HTTP
Client. Go Smalltalk!

Hope this helps,
Steve

==========
Steve Waring
[hidden email]
http://www.dolphinharbor.org/dh/harbor/steve.html

Steve,

> As for my motivation, the first release of Spray used MSXML for both the
> parser and http transport. I ended up getting frustrated at not being able
> to track down or fix bugs. While some of those bugs turned out to be mine,
> the older versions of MSXML do contain bugs. In addition I found that
> deploying applications that depend on the MSXML control was a major source
> of problems.

Well said.  Another benefit is that while the MS  binary produces an error
message that mentions line and position, debugging into Smalltalk code makes
it a **lot** easier to find the source of a problem.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Steve Waring" <[hidden email]> wrote in message
news:ao15jp$igpcp$1@ID-> The
> There was no work done on standardizing the clients. I would imagine the
> difficulty with this would be what exceptions are signalled, and what the
> user can do if the send doesnt work as expected. Is this standardized for
> CORBA across the Smalltalk dialects?

yes, there is CORBA version of  instance based exception handling. In other
words corba implementation provides you a dictionary with exception
instances which you can use like this:

exceptionInstance corbaHandle: [:ex | .. exception handler ] do: block

I assume that at the time standard has been written, the instance based
error handling was prevailing (or at least in the particulary comminty).
Anyway, this can be reasonably well implemented in dolphin. How strictly
other smalltalks implement this i am not sure. Also other parts of the
smalltalk mapping are more fuzzy even in the standard.

> Hope this helps,
> Steve

yap, thanks Steve.

rush