WebClient

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

WebClient

Tobias Pape
Hey all

Re-reading an old blog post
        https://squeakingalong.wordpress.com/2010/05/05/webclient-and-webserver-for-squeak/
Can we make the last paragraph happen?

Best
        -Tobias




signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WebClient

Frank Shearar-3
On 15 May 2014 13:17, Tobias Pape <[hidden email]> wrote:
> Hey all
>
> Re-reading an old blog post
>         https://squeakingalong.wordpress.com/2010/05/05/webclient-and-webserver-for-squeak/
> Can we make the last paragraph happen?

(which is, for lazy folk,

> As a result, we now have what I think is a pretty decent HTTP server and client implementation for Squeak 4.1 and hopefully we can nuke HTTPSocket sometime soon. WebClient is superior in _every_ respect.
)

frank

> Best
>         -Tobias
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: WebClient

Chris Cunnington-4

On May 15, 2014, at 9:07 AM, Frank Shearar <[hidden email]> wrote:

> On 15 May 2014 13:17, Tobias Pape <[hidden email]> wrote:
>> Hey all
>>
>> Re-reading an old blog post
>>        https://squeakingalong.wordpress.com/2010/05/05/webclient-and-webserver-for-squeak/
>> Can we make the last paragraph happen?
>
> (which is, for lazy folk,
>
>> As a result, we now have what I think is a pretty decent HTTP server and client implementation for Squeak 4.1 and hopefully we can nuke HTTPSocket sometime soon. WebClient is superior in _every_ respect.
> )
>
> frank
>
>> Best
>>        -Tobias



I just read your blog post twice. I'm sure you're right about it being better, but if you could explain things in more detail that would be good.

1. A quick search in an image of mine says HTTPSocket is used 37 times: SMSqueakMap, SSVersion, FileStream, SocksSocket, MCHttpRepository, InstallerUrl. What happens to them? Do they all break?
2. Would this change only work for applications that already use the *WebClient-HTTP-override protocol in HTTPSocket?
3. Would this require the Adaptor pattern to keep older code working?
4. If I use Kom do I need to migrate somehow?

If you could provide more information about how this change would affect things that rely on it, then I'm all for it.

Chris
Reply | Threaded
Open this post in threaded view
|

Re: WebClient

Tobias Pape
Hey,

On 15.05.2014, at 17:41, Chris Cunnington <[hidden email]> wrote:

>
> On May 15, 2014, at 9:07 AM, Frank Shearar <[hidden email]> wrote:
>
>> On 15 May 2014 13:17, Tobias Pape <[hidden email]> wrote:
>>> Hey all
>>>
>>> Re-reading an old blog post
>>>       https://squeakingalong.wordpress.com/2010/05/05/webclient-and-webserver-for-squeak/
>>> Can we make the last paragraph happen?
>>
>> (which is, for lazy folk,
>>
>>> As a result, we now have what I think is a pretty decent HTTP server and client implementation for Squeak 4.1 and hopefully we can nuke HTTPSocket sometime soon. WebClient is superior in _every_ respect.
>> )
>>
>> frank
>>
>>> Best
>>>       -Tobias
>
>
>
> I just read your blog post twice. I'm sure you're right about it being better, but if you could explain things in more detail that would be good.
>
Attention, the post is not mine. It is an old one by Andreas.

> 1. A quick search in an image of mine says HTTPSocket is used 37 times: SMSqueakMap, SSVersion, FileStream, SocksSocket, MCHttpRepository, InstallerUrl. What happens to them? Do they all break?

Well, Andreas introduced that Compat layer
as you found out (Q2).
So they theoretically shouldn't.

(BTW, If SSVersion is from SqueakSource, how would it use HTTPSocket?)

> 2. Would this change only work for applications that already use the *WebClient-HTTP-override protocol in HTTPSocket?

There shouldn't be any other uses…

> 3. Would this require the Adaptor pattern to keep older code working?

An inverse for WebClient-HTTP so to speak…

> 4. If I use Kom do I need to migrate somehow?

I don't know.

>
> If you could provide more information about how this change would affect things that rely on it, then I'm all for it.

• We should be just concerned to migrate the core infrastructure
  (Monticello, Updates, SqueakMap if you want, Installer if necessary)
• Move HTTPSocket into its own package
• Deprecate HTTPSocket in 4.6 or 4.7
• Remove it in 4.7 or 4.8

I just jumped for it as I hat to answer questions regarding problems in HTTPSocket
and I just noticed that it is really due to be replaced, IMHO.

Best
        -Tobias



signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WebClient

Chris Cunnington-4

On May 15, 2014, at 1:21 PM, Tobias Pape <[hidden email]> wrote:

Hey,

On 15.05.2014, at 17:41, Chris Cunnington <[hidden email]> wrote:


On May 15, 2014, at 9:07 AM, Frank Shearar <[hidden email]> wrote:

On 15 May 2014 13:17, Tobias Pape <[hidden email]> wrote:
Hey all

Re-reading an old blog post
     https://squeakingalong.wordpress.com/2010/05/05/webclient-and-webserver-for-squeak/
Can we make the last paragraph happen?

(which is, for lazy folk,

As a result, we now have what I think is a pretty decent HTTP server and client implementation for Squeak 4.1 and hopefully we can nuke HTTPSocket sometime soon. WebClient is superior in _every_ respect.
)

frank

Best
     -Tobias



I just read your blog post twice. I'm sure you're right about it being better, but if you could explain things in more detail that would be good.


Attention, the post is not mine. It is an old one by Andreas.

Ah, my mistake. 

1. A quick search in an image of mine says HTTPSocket is used 37 times: SMSqueakMap, SSVersion, FileStream, SocksSocket, MCHttpRepository, InstallerUrl. What happens to them? Do they all break? 

Well, Andreas introduced that Compat layer 
as you found out (Q2).
So they theoretically shouldn't.
Great. 

(BTW, If SSVersion is from SqueakSource, how would it use HTTPSocket?)
SSVersion>>#registerSqueakMap: 
I imagine it was removed a long time ago from the SqueakSource code base. It looks like it was an idea that was not fully realized. I have no intention in using it for SMServer. 

2. Would this change only work for applications that already use the *WebClient-HTTP-override protocol in HTTPSocket? 

There shouldn't be any other uses…

3. Would this require the Adaptor pattern to keep older code working? 

An inverse for WebClient-HTTP so to speak…

4. If I use Kom do I need to migrate somehow? 

I don't know.

If you could provide more information about how this change would affect things that rely on it, then I'm all for it. 

• We should be just concerned to migrate the core infrastructure
 (Monticello, Updates, SqueakMap if you want, Installer if necessary)
• Move HTTPSocket into its own package
• Deprecate HTTPSocket in 4.6 or 4.7
• Remove it in 4.7 or 4.8

I just jumped for it as I hat to answer questions regarding problems in HTTPSocket
and I just noticed that it is really due to be replaced, IMHO.

Sounds like a great idea. 


Best
-Tobias