[BUG]Scampler-Posting, Authentication, Infinite Loop

Umur at Writeme umur at writeme.com
Fri Jul 4 08:50:48 UTC 2003


Yes there is pretty much overlap on the facilities needed for both
Comanche and a prospective HTTPClient. It would be nice to hear Comanche
people on what's needed...

I am also defending high reuse on server and client codes. First of all
both need the same HttpRequest and HttpResponse objects.

Recently I made a nice project: Each project has an embedded Swiki book
to use in place of normal workspace. Write your notes and code examples,
search and find them later. It is very nice to have your brainstorming
wiki attached to your project. Not to disturb existing wiki code and to
allow for computers without a network connection, I created a virtual
HttpSocket. Commanche is serving to it and Scamper is posting to it.

Unfortunately, because of the network rewrite, evolving comanche and
seaside, I found out that I cannot release that code without disturbing
somebody. 

I will be keeping an eye on the network rewrite so that my project
becomes something without side effects to the work of others.

-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of
Daniel Vainsencher
Sent: Wednesday, July 02, 2003 8:07 PM
To: The general-purpose Squeak developers list
Subject: RE: [BUG]Scampler-Posting, Authentication, Infinite Loop


In which case, let's hope some network savvy Squeaker decides to
implement a high quality HTTPClient. Could round out all those
significant improvements in the networking area Squeak has been going
through (network rewrite, Jabber support).

Maybe one of the Comanche people wants to weight in with their
perspective on what's needed...

Daniel

Brent Vukmer <bvukmer at blackboard.com> wrote:
> [snip]
> > 
> > Note that HTTPSocket is going away - since mir's Network
> > rewrite, the proper way to implement protocols is to use 
> > Clients. So a better direction might be to help implement the 
> > HTTPClient for the new framework in a way that can be 
> > controlled so that the problem you describe doesn't happen.
> > 
> > I'm not sure whether Michael still intends to implement
> > HTTPClient on his own
> [snip]
> 
> FYI, I asked Michael about this a few days ago; he said:
> 
> "I took [HTTP migration to network rewrite] out as too many 
> modifications and innovations are happening in Comanche and Seaside in

> that area.  And it won't really help to just rewrite the HTTPSocket. 
> The URI package came out of the initial attempt to rewrite the HTTP 
> related stuff."



More information about the Squeak-dev mailing list