[BUG]Scampler-Posting, Authentication, Infinite Loop

Umur at Writeme umur at writeme.com
Sun Jul 6 23:18:08 UTC 2003


Each URL directory published on the web by a Swiki Server is a Swiki
Book. Inside a book all references are auto maintained. 

Now I am opening a Scamper (still Scamper itself need pretty
enhancement) instead of a workspace. The URL is "here:" and I am inside
the embedded swiki book of that project. No clutter of workspace
windows: just keep creating new titles for your ideas, search, refactor
them later.

For that currently I am creating a specialization of scamper and swiki
so that it can do everything a workspace can do such as containing
arbitraty embedded morphs, linking to class comments, methods, linking
to smalltalk expressions, etc.

My dream is to be able to brainstorm while developing and writing
complete hypertext tutorials inside my projects.


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


That sounds interesting - what's a swiki book? 

How does it work?

Note that the network rewrite is already included - IIUC, the only thing
you need to wait for is the next version of Comanche...

Daniel

Umur at Writeme <umur at writeme.com> wrote:
> 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