[squeak-dev] Re: [Pharo-project] A point a.k.a excuse to you

> Keith, your email implies that you believe Pharo should be backwards
> compatible at some level with Squeak.  Part of the Pharo manifesto is
> not to be compatible.  So if you want to write code or have apis that
> work in a backwards direction from Pharo to Squeak, that's great.  I
> don't believe it's a goal for Pharo though.  The pharo process doesn't
> need a rethink at all as far as I'm concerned.
>
> thanks,
>
> Mike
>  

> Michael Roberts wrote:
>> Keith, your email implies that you believe Pharo should be backwards
>> compatible at some level with Squeak.  Part of the Pharo manifesto is
>> not to be compatible.  So if you want to write code or have apis that
>> work in a backwards direction from Pharo to Squeak, that's great.  I
>> don't believe it's a goal for Pharo though.  The pharo process doesn't
>> need a rethink at all as far as I'm concerned.
>>
>> thanks,
>>
>> Mike
>>
> No that is not what I am saying at all. Perhaps examples would help.
>
> Take Rio. Rio was designed from ground up to be a replacement for a the
> present non-modular kernel facility FileDirectory. It is a discrete
> loadable module.
>
> Wild and horrible uses of FileDirectory are spread around the image in
> lots of places, so one thing that Rio tries to do is to anticipate use
> cases, so that the users of Rio dont have to implement File handling
> code in their stuff, and so we help to keep the module boundary clear.
> For example you can ask Rio to get you the next version of a file -
> 'myfile.2.txt' asFile nextVersion = 'myFile.3.txt. That facility in
> itself potentially lightens SmalltalkImage.  If you want to read Xml
> files, you can subclass File, with FileXML, define the #validExtensions
> that it handles, and implement contents/contents: This means that your
> code only needs to send, 'myfile.xml' asFile contents, to get the model.
> There are all sorts of things like that.
>
> With Rio as a front end to File and Socket streams it is perfectly
> possible to innovate on them without users of Rio being any the wiser.
> If I do 'myFile.3.txt' asFile contents, it wouldn't care whether it was
> Squeak streams Nile or Flow behind the scenes. 'http://www.google.com'
> asFile contents, now means that I dont have to care about whether
> HttpSocket is doing the work with a RWBinaryOrTextStream in 3.7 or
> HTTPClient returning a MultiByteStream thingy in 3.8 or some other new
> facility.
>
> So, Rio demonstrates that it is possible to innovate, on a kernel
> module, and you dont need to break anything to do it. Secondly by
> thinking about APIs and module interface abstractions in this way, you
> can define specific interfaces and bottlenecks, that potentially turn
> the ball of tangled string into something designed and architected.
> There are perhaps hundreds of other modules that could use the same
> treatment.
>
> Rio loads into all squeak images I have tried it in, so this then means
> that any of my file handling code will work in all images. This benefit
> comes from managing Rio as module external to the main image. Rio also
> comes in two sizes, a Rio-Kernel, and a Rio-Base, with smaller images in
> mind.
>
> Having done this, the question of moving the kernel over to make use of
> the new code arises, this also can be achieved without breaking anything
> for users that have had Rio available for 2 years in every image that
> their code was running in. I.e. Sophie, Croquet, Seaside, Gjallar,
> Magma, Etoys, can all migrate their file handling code to the new Rio
> API now, even if they are using Squeak 3.7/3.8, without having to
> upgrade to the latest squeak. When they do update, they will be pleased
> to find that their file handling code works, as well as their
> gzipping/archiving/remote file handling/and website accessing code.
>
> Installer follows the same principles, abstracting an api, freeing the
> backend to be either old code or new code. If you dont have Universes
> loaded, then defining Installer>>#universes to call #sake as a fall back
> would use Sake/Packages and get identical results, your users would be
> none the wiser. If you dont have SqueakMap loaded, then defining
> Installer>>#squeakmap to call #websqueakmap instead, would again give
> your users identical results. and you thought that Installer was just
> for loading things. Edgar has pointed out that you could use CodeLoader
> for that, but thats not the point of installer, Installer is providing a
> DSL for loading things that provides an architectural layer of
> isolation, and thus both inherrent forward and backward compatibility. I
> expect my image building scripts to work identically with Monticello2 in
> squeak 3.16 as they do now with Monticello 1.5 in Squeak 3.7.
>
> Scripter (who here even knows that Scripter exists?) does the same, if
> you want to write code to close or tile all the windows, after the
> installing process has left a mess. Scripter can be the interface to
> whatever backend GUI there happens to be whether it is
> ToolBuilder/Tweak/Morphic.
>
> Same again with Logging, is a front end abstraction to all of the three+
> logging backends out there. I can remove the hardwired calls to
> Transcript that scatter the image and replace them with a single api to
> multiple backends, both past (Transcript) present (Syslog) and future
> (seaside per-user session logging framework).
>
> Oh, and again with Sake/Packages.... why does Sake/Packages define class
> tasks? You can write a task that depends upon a task which removes
> certain method selectors. You could just call Behaviour direct. Its
> another  architectural layer, that frees up the back end to be old or
> new code as far as Sake task writers are concerned. I can write a task
> that says, "if you find this Class with a method categorised as so, then
> it needs to be recategorised as such", in such a way as this task would
> run in all images.
>
> Oh and again SystemEditor... another layer of abstraction for compiling
> and loading code atomically.
>
> So if you think about it, those who know about the compiler could be
> considering how to write their stuff, so that it logs to the Kernel
> Logging API (which is valid even if Logging isnt Loaded). They might
> consider connecting to SystemEditor in preference to providing a direct
> api, and another abstracted pluggable Module is needed to handle source
> code files (replacing RemoteString/ChangeSets etc), with Rio as the
> local/remote file API.
>
> Do you get the idea now?
>
> For the same treatment to be available for more significant chunks of
> squeak, we would need atomic loading to work. Now the code to provide
> atomic loading for everyone has been available for over a year, and it
> works if you dont use traits. So where is the expertise to really get it
> working for everyone with traits?
>
> The only difficulty with this approach is that you might need slightly
> different bits to make your NEW code load into older images. This
> problem is reasonably easily addressed with Installer-Scripts
> (LevelPlayingField+) and Sake/Packages.
>
> I fully agree with Matthew about core packages like Collections. BUT and
> this is the big but. If you are going to do that kind of thing, you need
> to think about it, plan it, and create and participate in a process that
> supports everyone is diverse images using and testing that package. From
> what I have seen there is only one person on the Pharo team that
> understands what LevelPlayingField is for, and how to use it.
>
> The biggest risk to this approach is if some other folks decide to fork
> some significant architectural component in a completely incompatible
> manner, without thinking about any bigger picture at all.
>
> Matthew's comment about how our tools are only just getting there isnt
> that relevant to the point that I am making. I didnt need a test and
> build server to innovate Rio for everyone rather than just for the image
> I am using (trouble was I was using 3 different images), all I needed
> was an inclusive attitude rather than an exclusive attitude.
>
> cheers
>
> Keith
>

>
>> build server to innovate Rio for everyone rather than just for the  
>> image
>> I am using (trouble was I was using 3 different images), all I needed
>> was an inclusive attitude rather than an exclusive attitude.
>>
> Dear All,
>
> I was trying to implement FileHttpExecutive in Rio today, I wanted to
> perform a GET, and have Rio informed of the File size as soon as the
> headers have been downloaded. As an alternative it would also be  
> nice to
> be able to send a HEAD request prior to getting the whole file. I also
> want to read the stream as it is coming in, since Rio already can  
> buffer
> ftp reads direct to a file, or other destination.
>
> About 5 minutes looking at the code showed me that this was pretty
> impossible. There was no clean way to subclass HTTPSocket and have it
> hold a handle on my file instance and report that information to me,
> since most of the business is performed on the class side (why do  
> people
> do that?) My only option is probably to subclass HTTPSocket, inserting
> some Notifications in there, and use exception handlers to collect  
> the data.
>
> So... would anyone out there be willing to rewrite HTTPSocket/Client
> from scratch so that it is well designed and so on from the ground up?
> Assuming that Socket will remain common between Squeak/Pharo etc, it
> could also provide an abstraction onto the Curl plugin as well. This  
> new
> module would of course be for the benefit of all.
>

> Philippe Marschall wrote:
>> 2009/3/3 Göran Krampe <[hidden email]>:
>>> Hi!
>>>
>>> What about perhaps looking at what has already been done, like:
>>>
>>> http://map.squeak.org/package/15f42ec1-e93e-4bcf-ab2b-6746ae9d413f
>>> http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040
>> Both of these links are dead.
>
> Good that SM has a server side cache then! :) If you use SM package  
> loader it will at least download the last one properly. Using  
> Firefox you can get at the server side cached file by adding "/
> cache" like this:
>
> http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040/autoversion/1/cache
>
> ...you don't get the proper filename, but if you rename it - it  
> should work.
>
> regards, Göran
>
>

> On Mar 3, 2009, at 2:40 AM, Göran Krampe wrote:
>
>> Philippe Marschall wrote:
>>>
>>> 2009/3/3 Göran Krampe <[hidden email]>:
>>>>
>>>> Hi!
>>>>
>>>> What about perhaps looking at what has already been done, like:
>>>>
>>>> http://map.squeak.org/package/15f42ec1-e93e-4bcf-ab2b-6746ae9d413f
>>>> http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040
>>>
>>> Both of these links are dead.
>>
>> Good that SM has a server side cache then! :) If you use SM package loader
>> it will at least download the last one properly. Using Firefox you can get
>> at the server side cached file by adding "/cache" like this:
>>
>>
>> http://map.squeak.org/package/8644a5ff-923c-438f-b5b0-a281de346040/autoversion/1/cache
>>
>> ...you don't get the proper filename, but if you rename it - it should
>> work.
>>
>> regards, Göran
>>
>>
>
> I have downloaded these cache files and will take a look at them after I
> look after I've checked out Swazoo as Janko recommended.  Obviously,
> currently maintained code is preferred to orphaned code, but I'm willing to
> use whatever I need to as a starting point... just rather surprised that
> this isn't an issue for more people.  Is it just a case that not many people
> are developing client-side HTTP code with Squeak these days?

> .. cross posted to swazoo-dev, pharo, swazoo-devel, aida, seaside.
>
> Phil (list) pravi:
>> On Mar 2, 2009, at 9:16 PM, Keith Hodges wrote:
> ...
>>> So... would anyone out there be willing to rewrite HTTPSocket/Client
>>> from scratch so that it is well designed and so on from the ground  
>>> up?
>>> Assuming that Socket will remain common between Squeak/Pharo etc, it
>>> could also provide an abstraction onto the Curl plugin as well.  
>>> This new
>>> module would of course be for the benefit of all.
>
>> I too am looking for a better solution but haven't found one yet.  
>> I am
>> interested in looking at anything better if it exists and am  
>> willing to
>> lend a hand to helping work on such an effort as well.
>
>> As I haven't found a solution yet, I have started to implement my own
>> HTTPRequest and HTTPResponse classes which will (for now) be used  
>> as a
>> front-end to a hacked up HTTPSocket.
>
> What if we rather make a Swazoo-Lite, that is a subset of Swazoo just
> with a HTTP client and a light HTTP server?
>
> That way we will avoid yet another implementation of HTTPRequest and
> Response classes , but we will reuse a proven and tested ones from  
> Swazoo.

>
> Best regards
> Janko
>
>
>
> --
> Janko Mivšek
> AIDA/Web
> Smalltalk Web Application Server
> http://www.aidaweb.si
>