ESUG will sponsor the XMLRPC project!
Locked
12
12
Re: ESUG will sponsor the XMLRPC project!
 
|
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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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 <[hidden email]>: > 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ESUG will sponsor the XMLRPC project!
|
|
In reply to this post by Adrian Lienhard
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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
NoSQL binding status and more (was Re: ESUG will sponsor the XMLRPC project!)
|
|
In reply to this post by Adrian Lienhard
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ESUG will sponsor the XMLRPC project!
|
|
In reply to this post by Stéphane Ducasse
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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ESUG will sponsor the XMLRPC project!
|
|
On Thu, Jul 1, 2010 at 11:06 AM, Noury Bouraqadi <[hidden email]> wrote:
I'd like to have a mechanism similar to what used in other places (example in robotics http://vote.gostai.com/forums/37683-general). +1 Laurent
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ESUG will sponsor the XMLRPC project!
|
|
In reply to this post by Stéphane Ducasse
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: NoSQL binding status and more (was Re: ESUG will sponsor the XMLRPC project!)
|
|
In reply to this post by Göran Krampe
goran
it would be great to consolidate such information on pharo book with pointers to the associated source repository. Do you have a bit of time for that? Stef On Jul 1, 2010, at 12:10 AM, Göran Krampe wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ESUG will sponsor the XMLRPC project!
|
|
In reply to this post by Janko Mivšek
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. 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). 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. 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ESUG will sponsor the XMLRPC project!
|
|
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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Sven Van Caekenberghe
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 <[hidden email]> And REST+JSON is easy to do with what is available in Pharo/Seaside/WebClient: -- ================================================= 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Germán,
Seaside 3 includes the JSJsonParser Hernán 2010/7/4 Germán Arduino <[hidden email]>: > 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 <[hidden email]> >> >> 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 >> >> [hidden email] >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Thanks Hernan, Sven said the same in private mail.
Thanks both. 2010/7/5 Hernán Morales Durand <[hidden email]> Germán, -- ================================================= 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |