> But it appears from my limited understanding of both Seaside and HV
> that they have different philosophies and perspectives and neither
> is wrong.
Different philosophies in some places, very different in others.  For
example, Seaside's HTML rendering is basically a combination of ideas
from HV and WebObjects, with a lot of Lisp influence - and I would say
the basic philosophy matches pretty well with Goran's.
On the other hand, you're right that the treatment of URLs is very
different - Seaside basically uses the URL (and the HTTP request in
general) as an opaque information vector that the developer never has
to deal with (unless they really want to - you *can* have bookmarkable
pages in Seaside, but I admit that it's a little awkward).  HV, like
most web frameworks, makes the HTTP request the central focus of the
application.
However, I still have hopes that they could be unified.  Marcel Weiher
posted a long time ago to the Seaside list about "micro-sessions" -
the idea that an application could be made up of a large number of
very short sessions of a few page views each.  The links within a
micro-session would be Seaside-like: opaque, meaningless urls, relying
heavily on server-side state, dealing with closures and continuations
rather than dictionaries of request parameters.  However, the links
between micro-sessions would be more traditional (HV-like).  A
bookmark would presumably take you back to the beginning of the last
micro-session.
Avi

I don't know either - I probably need to play with Seaside first. But
note that HV is very simple, I am not sure it adds much by putting it
inside Seaside - perhaps Avi has more to say on that matter.
Also HV uses a few tricks that affects how you build your apps - the
trick on my mind is the "building forms twice"-trick. The trick is IMHO
neat, but it does affect how your apps look/work.
Example (using latest unreleased HV, the #ifPressed: is new):
simplefield
 "This method is called when accessing http://localhost/hello.
 It is first called with a GET thus building the form with an empty
 text field and showing it. The #postForm defaults to an POST url
 pointing to this method again. So when the user press submit
 we end up here again and the form is built the second time.
 This time around the builder object sees that there is a value
 for the textfield and puts that into the HVHtmlInputText instance -
 this happens when the widget is created using the #inputText method,
 so that we can get it by sending #value to it later in the method."
 | builder field button |
 builder _ self builder.
 builder start; h1: 'Howdy!'.
 builder p: 'What is your name?'.
 builder postForm.
 field _ builder inputText.
 button _ builder submit.
 builder endForm.
 builder p: 'Your name is ', (button ifPressed: [field value]
ifNot:['unknown!']), '!'.
 builder hr; srcLink; end.
 ^builder
> Jimmie Houchin
regards, Göran