> First, a "continuation ID" means there has to be a continuation > stored on the server (or else you'd be saying "continuation state", > not "continuation ID"). This is still stateful, even if the application > in question doesn't always need it.

Of course the continuations approach is for stateful applications. Which serious business orientated applications do you want to write without state?

> Second, the existence of a "sitemap" indicates a centralized architecture. > A decentralized web object framework wouldn't have such a thing as a "site map". > Take a look at this site... objects nest within objects, as is visible by their > URLs. And as data is added, the trees grow and change. That's not > possible with a single static "site map".

As you refer to the Cocoon sitemap: It's not one single static sitemap. You can nest as many sitemaps as you need. Then the sitemap is "only" a mapping between URI space and applications (in Cocoon we use pipelines) which serve this URI. We do it explicitly and not implicitly (like the file/script to URL mapping of e.g. httpd.)

> URLs should represent persistent things, or methods upon persistent things. > That's what the web is.

As long as you can rely on stateless applications fine - but what happens if your requirements grow? How can you implement the fact "a user is logged in" without a state on the server in a safe way?

> Trying to use continuations for a web application > just means you don't really understand what the web is for,

What is the web for? (just curious)

> like a programmer > who writes a highly-modal GUI, fighting the event-driven model every step of > the way. Like GUIs, Web apps naturally fit to an event-driven asynchronous > messaging model. Even better, they usually fit a transaction-per-event model, > which makes them even easier to write than GUIs.

For simple requirments you can use simple technologies but once again, how do you handle states or if you say we don't need state at all how to you implement things like "a user is logged in" in a safe way?

> To me, the only legitimate

Sorry, I don't like your wording here: "legitimate" sounds like the one and only allowed solution and all others are wrong/idiots/...

... our world doesn't work this way ...

> use of cross-event continuations in a web application > is to model the state machines of published persistent objects. For example, > a web workflow object might use continuations to track the stage of the workflow > instance. But, that is something that occurs behind the REST representation of > the workflow instance, because the continuation is shared for everyone referencing > that instance. In other words, such a continuation is not part of the UI view, > it's part of the application domain model.

Cheers, Reinhard

PS You're of course welcome to join dev@cocoon.apache.org!!