On Jul 1, 2010, at 1:09 PM, Sven Van Caekenberghe wrote: > Since this is becoming a more general discussion, I can no longer resist from > commenting. This is a difficult discussion with many different opinions, > depending on where you stand. All points made up until now are each valid, > next is just my opinion and experience. > > Summary: REST with JSON or simple XML as encoding over HTTP/HTTPS using > standard or custom authentication/authorization is the future. Given enough > high quality standards based tools/frameworks in Smalltalk doing a protocol > client or server is quite easy. Most of the necessary tools/frameworks are > already there. If we have to encourage something, it should be finishing or > cleaning up those basic parts.
Yes! > Over the years I (like probably many others in their niches) have > implemented, published and maintained in Common Lisp: an XML-RPC client and > server, an XML parser, an HTTP client and server and SOAP with WSDL. As well > as many others internally (memcached client, JSON parsers, REST frameworks, > ...). > > Of course, even if it is fun and not that hard to implement them, not > everybody has to do that, reusable code is nice to have. > > That is why I was happy to find that Smalltalk/Squeak/Pharo in 2010 now has > all that I need and even lots more that I didn't expect (except HTTPS but > there is some renewed activity there). What I would really like from you the community is to build a map of the tools and available solutions we could have a chapter on book.pharo-project.org I think taht this is really important to document that. > > I know that VisualWorks has a couple of very nice frameworks/libraries for > some of some classic enterprise technologies. That does not yet mean that > Pharo needs them (all) as well. > > I think what the Pharo project is doing, a clean/mean open enterprise ready > Smalltalk is way more important. I started a couple of months ago on VW, > tried Pharo as an alternative and was very pleasantly surprised by the > overall quality: I don't want to go back! :) > In our company we decided many years ago to stop using over complex > enterprise technologies like EJB, most of J2EE, SOAP, especially WSDL, even > XML (ever tried one or more namespaces, encodings, binary data ?), as long as > we are in control. Sometimes you have no choice, but these parts of a project > then typically become a PITA. Most SOAP+WSDL interfaces that you come across > are automatically generated with 1 click from internal .net classes without > any external API design, let alone cross platform testing. > > Even in the Java enterprise world there is a strong movement towards simpler > technologies. And as others mentioned here, many internet APIs are going in > the same direction (or at least offer multiple variants, I like Amazon's AWS > APIs a lot for example). > > So, for me, the fundamentals, clean/mean image, excellent IDE tools, fast vm, > good networking, basic http(s) client and server, crypto, xml and json > parsing, db access, deploy options, documentation and of course community are > the most important. Thanks Sven > > My 2c, > > Sven > > On 01 Jul 2010, at 11:33, Janko Mivšek wrote: > >> Hi guys, >> >> Commercially speaking I see a need for a better Web Services support in >> Squeak/Pharo, here I mean both SOA and REST Web Services. >> >> XML-RPC is closer to SOA Web Services so this project could be changed >> to improve current SOAP and add the WSDL support? >> >> We currently have SoapOpera [1] and SoapCore [2] from Masashi Umezawa, >> maybe his work can be a good starting point to extend it and make a >> really good and useful SOA Web Services implementation in Smalltalk? >> >> I namely use SOA Web Services (SOAP+WSDL) quite frequently on my >> commercial projects in VisualWorks. With good tools it is certainly the >> easiest way to connect to other systems and to other >> languages/technologies. >> >> And remember: SOAP means Simple Object Access Protocol. While that >> Simple is nowadays very questionable, that Object Access is certainly >> not. I mean, SOAP is a protocol to pass messages between objects in >> different OO systems. Smalltak as an OO system therefore needs a good >> SOA Web Services support! >> >> [1] http://map.squeak.org/package/d17a284e-6a2d-4fea-b4bc-65c82bc45001 >> [2] http://map.squeak.org/package/dab9b621-00d2-41c3-966c-458bf62b8008 >> >> On 30. 06. 2010 20:53, Stéphane Ducasse wrote: >>> Philippe this is good that you reacted. The point of esug is to support >>> actions >>> that will help people so probably XML-RCP is not a really good choice. >>> Now what would be good is to have a map of current techno and their support >>> for smalltalk. Then act to fill up the gaps. >>> >>> Stef >>> >>>> >>>> It doesn't strike me as a forward looking investment. IMHO XML-RCP is >>>> something that will only get used less in the future, not more. The >>>> value you get from an XML-RCP implementation will become less and less >>>> as fewer services support it. >>>> >>>> But then again ESUG is free to spend their money on what they seem fit. >>>> If they disagree or decide the current use is big enough, I have no >>>> problem at all with this. >>>> >>>> Cheers >>>> Philippe >> >> >> -- >> Janko Mivšek >> AIDA/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
