Hi!  Thanks for your thoughts.

 > 1. Enabling mailto: url's. The current version of my email client =
 > supports the following:
 > 
 > (Smalltalk includesKey: #EmailWindow) ifTrue: [
 > 	(Smalltalk at: #EmailWindow) beginNewMessageTo: 'joe at abc.com'
 > ].


Cool!  I'll stick this in real soon.  It means having a link that
doesn't actually change the page, but that's needed anyway.


 > 2. Performance - I think there are still some gaps. I have found that =
 > getting to the squeak swiki at Ga Tech sometimes is very slow even =
 > though it seems that the data comes across the modem in a reasonable =
 > time. I tried raising the priority of the Process doing the download to =
 > #highIOPriority and that helped a lot until it failed to get the data =
 > and got stuck in a "data was slow" loop. I am going to (for my own =
 > edification) to try to understand the process scheduling mechanism and =
 > perhaps that will shed some light on the matter.


As I understand it works like this:

   1. There is no automatic preemption between 
      threads of the same priority

   2. Between threads of different priority, the highest 
      thread that can run, does run


I'm not happy either with the way Scamper scedules its work, either.
Either you put it in a background thread, which means a busy UI can
slow or even stop it (try running a BouncingAtomsMorph while
downloading something!), or you put it in a normal-to-high priority
thread and the UI gets frozen when the thread actually starts working.
Either way someone loses.

The solution I'd really like is to get the parsing sped up.  If it
only took a quarter to a half of a second, it wouldn't matter if it
stops the UI.

Another solution is to make the parser periodically yield somehow.
This could be done via a hack like running a high-priority thread that
preempts the parser thread every once in a while, or it could be done
by making the parser interrupt itself every once in a while.  Either
way is pretty ugly in my opinion.

Yet another way is to make Squeak threads preemptive; I think it's
easy to do (run a high priority thread that periodically causes the
current thread (other than itself) to yield).  But I don't know all
the implications of this....



 > 
 > 3. Addition of more html types - while I understand, and in large =
 > measure agree with, your bias towards text types, more will be needed =
 > to make this a replacement for a regular browser. Images come to mind =
 > immediately (though a user option in the matter would be nice). A =
 > reasonable benchmark might be a site like www.apple.com which looks =
 > nice and doesn't have a lot of bells and whistles - Scamper renders it =
 > a bit too minimally.


Agreed.  I think I'll actually have images working in a day or two.

Further down the line, I want to make Scamper notice content-types on
pages that are viewed, too.  For instance, plain text and binary data
at least should be recognized; currently they are both parsed as HTML.



 > 
 > I'll let you know more as I spend more time with it.
 > 


Okay--thanks a lot for your input!


Lex