Yes, you are right. 2010/6/26 Lawson English <lenglish5@cox.net>:

On 6/26/10 10:27 AM, Germán Arduino wrote:

...

Hi Folks,

I'm very happy of announce that ESUG will be sponsoring my work to develop a XMLRPC client interface, as I comment on my blog:

http://germanarduino.blogspot.com/2010/06/esug-will-sponsor-xmlrpc-project.h....

I want to thank publicly to Stéphane Ducasse, Alain Plantec, Nuory Bouraqadi and ESUG, as they are sponsoring this initiative under the "support your project" program, described in http://www.esug.org/Promotion/Project . Thanks you very much ESUG.

Any comment or suggestion to this project is more than welcomed.

Cheers.

https support is important for many use-cases with xmlrpc... But https support is very minimal, at best, in squeak.

Lawson

-- ================================================= Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com =================================================

Hi Philippe: What is bad with xmlrpc? A lot of sites are using it to expose its data.... Cheers. Germán. 2010/6/27 Philippe Marschall <kustos@gmx.net>:

On 26.06.2010 19:27, Germán Arduino wrote:

...

Hi Folks,

I'm very happy of announce that ESUG will be sponsoring my work to develop a XMLRPC client interface, as I comment on my blog: http://germanarduino.blogspot.com/2010/06/esug-will-sponsor-xmlrpc-project.h....

I want to thank publicly to Stéphane Ducasse, Alain Plantec, Nuory Bouraqadi and ESUG, as they are sponsoring this initiative under the "support your project" program, described in http://www.esug.org/Promotion/Project . Thanks you very much ESUG.

Any comment or suggestion to this project is more than welcomed.

WTF?! It's 2010 and you're implementing XMLRPC. Srsly guys? What's next CORBA?

Cheers Philippe

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- ================================================= Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com =================================================

On 27.06.2010 15:39, Germán Arduino wrote:

Hi Philippe:

What is bad with xmlrpc? A lot of sites are using it to expose its data....

Like whom? Cheers Philippe

On 06/28/2010 12:25 AM, Germán Arduino wrote:

As flickr,

Besides REST and SOAP

blogger,

Nope, not any more.

wordpress,

ok

Joomla sites,

ok

Google blog search,

Couldn't find anything about it. Google is standardizing on GData and "AJAX". Even SOAP is being phased out.

Drupal sites,

Moving away from XML-RPC like anybody else.

delicious,

Couldn't find anything XML-RPC related, seems to use "REST".

zope,

OK.

products as SAP,

Still? I would have assumed they moved on.

to mention a few that I have in mind now....

I means, not only web sites, also products and I think also that is a compact protocol that could permit to implement an API to servers / products easily.

My impression is that people either moved from XML-RCP to SOAP or abandoned the idea and went to REST. I don't know anybody who considers it for new projects. Cheers Philippe

Thanks. May be german should have a look at this solution instead of XML-RCP. Stef

...

My impression is that people either moved from XML-RCP to SOAP or abandoned the idea and went to REST. I don't know anybody who considers it for new projects.

As Philippe stated, many projects are moving to REST. REST/JSON webservices are getting all the hype these days...

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Sven: Which JSON are you using? The package I know from Squeaksource (http://www.squeaksource.com/JSON.html) doesn't includes the class JSJsonParser. Cheers. Germán. 2010/6/28 Sven Van Caekenberghe <sven@beta9.be>

And REST+JSON is easy to do with what is available in Pharo/Seaside/WebClient:

client := WebClient new. client authCredentialsBlock: [:client :realm :fail | client username: '680'; password: ((MD5 new hashMessage: 'secret') hex) ]. response := client httpGet: 'http://api.t3-platform.net:9000/users/680'. JSJsonParser parse: response content.

Sven

PS: Only HTTPS is missing ;-)

On 28 Jun 2010, at 13:35, Stéphane Ducasse wrote:

...

Thanks. May be german should have a look at this solution instead of XML-RCP.

Stef

...

...

My impression is that people either moved from XML-RCP to SOAP or abandoned the idea and went to REST. I don't know anybody who considers it for new projects.

As Philippe stated, many projects are moving to REST. REST/JSON webservices are getting all the hype these days...

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- ================================================= Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com =================================================

Thanks Hernan, Sven said the same in private mail. Thanks both. 2010/7/5 Hernán Morales Durand <hernan.morales@gmail.com>

Germán, Seaside 3 includes the JSJsonParser

Hernán

2010/7/4 Germán Arduino <garduino@gmail.com>:

...

Hi Sven:

Which JSON are you using?

The package I know from Squeaksource ( http://www.squeaksource.com/JSON.html) doesn't includes the class JSJsonParser.

Cheers. Germán.

2010/6/28 Sven Van Caekenberghe <sven@beta9.be>

...

And REST+JSON is easy to do with what is available in Pharo/Seaside/WebClient:

client := WebClient new. client authCredentialsBlock: [:client :realm :fail | client username: '680'; password: ((MD5 new hashMessage:

'secret')

...

hex) ]. response := client httpGet: 'http://api.t3-platform.net:9000/users/680 '. JSJsonParser parse: response content.

Sven

PS: Only HTTPS is missing ;-)

On 28 Jun 2010, at 13:35, Stéphane Ducasse wrote:

...

Thanks. May be german should have a look at this solution instead of XML-RCP.

Stef

...

...

My impression is that people either moved from XML-RCP to SOAP or abandoned the idea and went to REST. I don't know anybody who considers it for new projects.

As Philippe stated, many projects are moving to REST. REST/JSON webservices are getting all the hype these days...

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- ================================================= Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com =================================================

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- ================================================= Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com =================================================

2010/6/28 Philippe Marschall <philippe.marschall@netcetera.ch>:

On 06/28/2010 12:25 AM, Germán Arduino wrote:

...

As flickr,

Besides REST and SOAP

...

blogger,

Nope, not any more.

...

wordpress,

ok

...

Joomla sites,

ok

...

Google blog search,

Couldn't find anything about it. Google is standardizing on GData and "AJAX". Even SOAP is being phased out.

...

Drupal sites,

Moving away from XML-RPC like anybody else.

...

delicious,

Couldn't find anything XML-RPC related, seems to use "REST".

...

zope,

OK.

...

products as SAP,

Still? I would have assumed they moved on.

...

to mention a few that I have in mind now....

I means, not only web sites, also products and I think also that is a compact protocol that could permit to implement an API to servers / products easily.

My impression is that people either moved from XML-RCP to SOAP or abandoned the idea and went to REST. I don't know anybody who considers it for new projects.

Blogger and Google in general yes, are moving to GData but xml-rpc is still suported. But I understand your point, you think that isn't worth to invest in this protocol. I need to think about. Cheers. Germán.

On 28/06/2010 22:18, Germán Arduino wrote:

Blogger and Google in general yes, are moving to GData but xml-rpc is still suported.

But I understand your point, you think that isn't worth to invest in this protocol.

I need to think about.

It is still in use though, and as mentioned elsewhere on this thread you don't get to dictate the protocol the people on the other side use :)

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

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi: Myself was playing a bit with Cassandra (also developing a rudimentary console). As Smalltalk is already included in Thrift, is not so hard to access and use a Cassandra store. Anyway I personally largely prefer the objects databases :) But indeed these sort of DBs (as Cassandra) are being more and more populars, I think that this is mainly for its HA features. Cheers. Germán. 2010/6/30 Adrian Lienhard <adi@netstyle.ch>:

Taking about more future oriented stuff, I think it would be nice to have good support for document DBs (like CouchDB and MongoDB) and key/value stores (like Redis). At least for the former category of DBs, I know that a few people have been working on DB clients (see squeaksource.com) but I don't know how complete and stable they are.

Adrian

On Jun 30, 2010, at 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

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I'd like to have a mechanism similar to what used in other places (example in robotics http://vote.gostai.com/forums/37683-general). People can vote/help to choose the most important projects. This helps focusing the community effort and fundings too. Noury On 30 juin 2010, at 23:45, Stéphane Ducasse wrote:

Now what would be good is that as a community we identify key points and put money on the table. I'm sure that we can get some nice and smart south american programmers and esug can help. But this would make sense to do it as a community effort. May be we should do a call.

Stef

On Jun 30, 2010, at 10:36 PM, Adrian Lienhard wrote:

...

Taking about more future oriented stuff, I think it would be nice to have good support for document DBs (like CouchDB and MongoDB) and key/value stores (like Redis). At least for the former category of DBs, I know that a few people have been working on DB clients (see squeaksource.com) but I don't know how complete and stable they are.

Adrian

On Jun 30, 2010, at 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

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi! On 06/30/2010 10:36 PM, Adrian Lienhard wrote:

Taking about more future oriented stuff, I think it would be nice to have good support for document DBs (like CouchDB and MongoDB) and key/value stores (like Redis). At least for the former category of DBs, I know that a few people have been working on DB clients (see squeaksource.com) but I don't know how complete and stable they are.

Adrian

Braindump: For CouchDB there are two client libs on SS, one based on Curl and the other straight on SocketStream. Both are... quite limited, but I think they are pretty stable since the CouchDB API is RESTful its kinda easy. MongoDB has MongoTalk on SS by no other than Kent Beck. It looks quite ambitious and with a single little tweak the tests went green for me. MongoDB has IMHO more "buzz" right now and CouchDB seems slightly "stalling". I would guess MongoDB will grab more and more developer mindshare as time goes by, since it fits better with most apps actually. I am not aware of any binding for Redis. And yes, Redis is "neat" in its own way. I wrote a quite ambitious binding for Tokyo Tyrant, its on SS and has tests too. I think it is stable, but I am not that interested currently. My next little project in this arena would be a binding for Riak, since I think it is next to MongoDB and CouchDB one of the more interesting ones out there. It also has a RESTful API just like CouchDB and using WebClient seems logical these days. Finally I think another *hole* in our toolshed is support for all the funky new cool MQ products. I started implementing STOMP the other day and it will just take an hour or two to get it finished. Yes, there is an AMQP protocol implementation on SS, but I found it... quite undocumented. Given the author it is probably very correct though. regards, Göran

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

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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project