December 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [OSProcess] Proposal for Pharo 1.2 compatibility
by Cyrille Delaunay Dec. 1, 2010

Dec. 1, 2010

Hello, I would suggest to replace the two methods -------------------------------------------------------------- OSPRocess class >> platformName "After Squeak version 3.6, #platformName was moved to SmalltalkImage " ^ ((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk platformName]) current platformName OSPRocess class >> osVersion "After Squeak version 3.6, #osVersion was moved to SmalltalkImage " ^ ((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current osVersion -------------------------------------------------------------- by: ------------------------------------------------------------- OSProcess class >> platformName ^ ((Smalltalk classNamed: 'OSPlatform') ifNil: [ (Smalltalk classNamed: 'SmalltalkImage') current ifNil: [^ Smalltalk platformName]]) platformName OSProcess class >> osVersion ^ ((Smalltalk classNamed: 'OSPlatform') ifNil: [ (Smalltalk classNamed: 'SmalltalkImage') current ifNil: [^ Smalltalk osVersion]]) osVersion ------------------------------------------------------------ to avoid deprecation messages when using it in Pharo 1.2. Does it looks good? I'm not able to publish on the squeaksource repository

4 7

Re: [Pharo-project] Transforming WSDL in a local model - Which HTTP client ? (was Web Services - SoapOpera problems)
by mkobetic＠gmail.com Dec. 1, 2010

Dec. 1, 2010

"Philippe Marschall"<philippe.marschall(a)netcetera.ch> wrote: > Yes, SOAP it not just some XML format. You have to sink a lot of > resources into the implementation and tool support. Keep in mind that > even Cincom with all their resources didn't manage to make their SOAP > library talk to SAP. They had to build a proprietary connector. That's not quite what happened, the SAP Connect relies on the WS stack to do the WS part, it adds SAP specific integration, and yes it also provides the alternative proprietary RFC protocol as well (not everything in SAP was exposed via WS at that point). Anyway, I can certainly sympathise with the sentiment expressed in this thread. IMO, CORBA comes out as the pinacle of simplicity when compared to the WS stack as it is today. The problem is not just the sheer number of specs, but also the laxity and vagueness of individual specs themselves. There's so much room for different interpretations of everything that interoperability beyond trivial examples is nearly impossible (generally the small monkeys just have to ape what the few gorillas decide to do). Anyway, the easiest in this case likely is to simply observe the communication of the PHP based solution and implement just that specific protocol. Each WSDL spec basically defines (whatever that means in the WS context) a custom protocol, you need just one of those, not all of them.

1 0

[Pharo-project] Protocol Buffers anyone?
by GÃ¶ran Krampe Dec. 1, 2010

Dec. 1, 2010

Hi! I want to build an API for Riak (awesome NoSQL db) and there is a choice of using HTTP or Protocol Buffers. Evidently Protocol Buffers offer a quite higher degree of performance so I am leaning towards that. Now, has anyone dabbled with implementing Protocol Buffers for Squeak/Pharo/Smalltalk? Couldn't find anything. regards, GÃ¶ran

1 0

Re: [Pharo-project] Squeaksource down
by Marcus Denker Dec. 1, 2010

Dec. 1, 2010

On Dec 1, 2010, at 8:16 AM, Alexander LazareviÄ wrote: > http://downforeveryoneorjustme.com/www.squeaksource.com It's up again. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] Squeaksource down
by Alexander LazareviÄ Dec. 1, 2010

Dec. 1, 2010

http://downforeveryoneorjustme.com/www.squeaksource.com

1 0