Avi Bryant wrote:
> On Thursday, October 30, 2003, at 03:38 PM, Jimmie Houchin wrote:
>
>> 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.

It's been a little while since I've seriously looked at Seaside.
But this is one part I really liked.

> 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.

To me putting state and such into the URL makes the app/page to user 
manipulatable. (From memory) When playing with Seaside a few weeks ago 
and going thru the tutorial, it seemed as if I could go back to the 
beginning by merely removing the session/state off of the URL.

If I can successfully authenticate the user I prefer to have any of that 
stuff stored server side and not at the disposal of the the user.

The most I would care to have is a user/session key in the URL.
The key could be  base64 or base256 or the largest baseWhatever that has 
URL permissable characters or something which would allow for a very 
small and brief (few characters) keys and still allow for enormous 
numbers of users/sessions etc.

If the key in the URL is to an old session, request the user to login 
(authenticate). If the user wishes to be anonymous set new session key 
in the URL. This would allow bookmarking to be successful even if a 
session key is embedded in the URL. Not the best of bookmarks, but users 
will do such.

> 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.

If much of Seaside and HV can be reconciled and possibly handled by 
app/server configuration and settings that would be alright.

That way we could have the behaviour we desire. Where important and 
desired, REST, bookmarkability, etc. For other places all the benefits 
and blessing of Seasides continuation based goodies. Maybe these 
settings could be URL based also.

So that http://www.mywebstore.com/shoppingcart/
could be a nice dynamic Seaside app with all the trimmings.

Just thinking outloud. :)
I am not a web framework expert. How to go about reconciling and making 
both parties happy? I don't know.

Jimmie Houchin