SocketStream bites again, warning to 3.8 (or earlier) users still using it

Hi folks!

We just dug deep into Gjallar in order to find a weird problem were our
multipart file upload field ended up putting its contents (the file)
into a nearby textarea input field. :)

First we suspected the multipart form fields parsing code in
KomHttpServer - but in fact, it turned out to be a bug in the old
SocketStream class (the one in 3.8).

Instead of figuring out *exactly* why upToAll: fails in this particular
case - we threw in FastSocketStream (we have been using it, but I missed
putting it in when building our latest dev image) - and the problem
disappeared.

Re-reading my class comment on FastSocketStream I mention one problem in
the old upToAll:, but this one seemed to be a different bug.

Anyway, the summary: Use FastSocketStream  :)

regards, Göran

[hidden email] wrote:

> Anyway, the summary: Use FastSocketStream  :)

The 3.8.1 updates replace SocketStream with your new version :-)

OK, time to release 3.8.1, fixes for SM or similar have to go in later ;-)

Michael

Hi!

Michael Rueger <[hidden email]> wrote:
> [hidden email] wrote:
>
> > Anyway, the summary: Use FastSocketStream  :)
>
> The 3.8.1 updates replace SocketStream with your new version :-)
>
> OK, time to release 3.8.1, fixes for SM or similar have to go in later ;-)
>
> Michael

Ah, right... hmmmm. The idea was to try to produce a cs that does the
same thing as the upgrade SM mechanism does. But do we really have to
bother? I mean, the update stream is on squeak.org - right? And the
upgrade of SM uses squeak.org too. So if one is down, the other is too.

Mmmm. So if we skip the idea of turning this into a cs - then I think it
is as simple as a cs with a preamble (or postscript) that does:

        SMSqueakMap bootStrap

...that would upgrade it to the *current* SM - whatever that is at the
time of applying the update. But frankly, as SM works today there is no
other version you can use in order to communicate with the server.

regards, Göran

>
> Anyway, the summary: Use FastSocketStream  :)

Already in 3.9 ;))))))))))

stef

On Aug 28, 2006, at 4:42 AM, [hidden email] wrote:

If I wanted to use SM in 3.8 and earlier in the meantime, could I  
execute this in a workspace to fix my local SM installation? This has  
been a real pain, as I don't use 3.9 for production work.

Colin

> [...]
>
> Anyway, the summary: Use FastSocketStream  :)

And what about this bug?

      http://bugs.impara.de/view.php?id=3265

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

This is definitely a pain - when working in older images, SqueakMap  
insists on updating - but the update fails because it expects apis  
that are not in that image.

It needs to be smarter about matching SM client version to Squeak  
image version - maybe I don't want to update.

On Aug 28, 2006, at 5:17 AM, Colin Putney wrote:

Hi!

Todd Blanchard <[hidden email]> wrote:
> This is definitely a pain - when working in older images, SqueakMap  
> insists on updating - but the update fails because it expects apis  
> that are not in that image.
>
> It needs to be smarter about matching SM client version to Squeak  
> image version - maybe I don't want to update.

It is not that simple. The server maintains the domain model - an
instance of SMSqueakMap. When you use the web UI to add packages, edit
releases etc - the server regularly makes an ImageSegment snapshot of
that SMSqueakMap instance.

The "client" images then have the exact same code - downloads the
ImageSegment and installs it into the image.

Net result: The client images need to have the same classes as the
server has. As it works *today* that is. I am not saying it couldn't
work differently.

Further:

I am not sure I grok the above sentence. The oneliner upgrades the code
in the image to be the current version of SM that is on SM itself. This
is typically the remedy for the "SMMaintainableObject blabla error" (old
SM code in an old image trying to install a new ImageSegment). Since all
images in a directory share the same "sm" dir - when one has been
upgraded the other images will not detect this and needs the above
oneliner.

> > This  
> > has been a real pain, as I don't use 3.9 for production work.

Not sure what 3.9 has to do with it.

regards, Göran

PS. Unfortunately the upgrade of SM into 3.8 had an unfortunate side
effect causing SM to not work in 3.7 and older (IIRC). This has to do
with multi byte strings etc. And yes, SM needs a rewrite/overhaul but I
am swamped right now with other things. :)

[hidden email] writes:
> The "client" images then have the exact same code - downloads the
> ImageSegment and installs it into the image.
>
> Net result: The client images need to have the same classes as the
> server has. As it works *today* that is. I am not saying it couldn't
> work differently.


Yeah, this is the main downside of shipping image segments around.

A simple way to avoid this is to export your data to XML or some other
semi-structured format before communicating over the network.  Then
you can very well have different versions of the software talking to
each other.  Actually, I find that frequently you do not even need
explicit versions; if simply ignore unknown message fields, and use
defaults for missing fields, then your system ends up being naturally
tolerant against version differences.


Looked at another way, this approach means you are free to change
around your internal data structures however you like.  So long as you
can produce the same XML messages when you talk on the network, you
are fine.


-Lex


PS -- When I say "export to XML", I do not mean to use automatic tools
that just happens to use XML somewhere.  I mean writing conversion
routines that save exactly the information you want to export.

Hi!

Lex Spoon <[hidden email]> wrote:
Yes, I have written XML import/export for quite an advanced domain model
and given a bit of care this is one nice benefit indeed.
At the same time it can be dangerous to let many versions of a software
"coexist" sharing the same model if you *do* happen to introduce changes
and "fail to realize" that older versions treat it differently.
 
> Looked at another way, this approach means you are free to change
> around your internal data structures however you like.  So long as you
> can produce the same XML messages when you talk on the network, you
> are fine.

But you will most likely still need to force people to upgrade at some
point if the XML needs to change. For example, in the beginning SM1 had
no notion of releases. For an SM1 client to use an SM2 map and still
"work properly" would have been hard while at the same time let the map
format accomodate that change. In short - software can not be backwards
compatible "indefinitely". Naturally. :)

Göran

PS. I will move from ImageSegments to XML or some other approach if/when
I get the time to do it. And of course, my offer for people to help
still stands. ;) (yes, Andreas threw together some XML code for SM, but
it still will take hours to get it working and up and running correctly
I am guessing. And if he disagrees I will gladly let him or anyone else
prove it. :))

[hidden email] puso en su mail :

> I will move from ImageSegments to XML or some other approach if/when
> I get the time to do it. And of course, my offer for people to help
> still stands. ;) (yes, Andreas threw together some XML code for SM, but
> it still will take hours to get it working and up and running correctly
> I am guessing. And if he disagrees I will gladly let him or anyone else
> prove it. :))
Why ?
All what is needed is a more "intelligent" ImageSegments .
Some what could consult a master Squeak image running somewhere, having all
info from Squeak day 1 to now for any remote request could be solved.

By the way Squeak was born in Apple in 96, so is ten years now.
When is the "birthday date" ?
Any celebrations planned ?

Edgar



       
       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas