cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Zisk <>
Subject RE: Cocoon2 Design
Date Wed, 31 May 2000 15:28:24 GMT
> Probably he was just arguing against putting logic into path
> part of the URL (like Turbine does currently). And I agree
> with this objection, I also don't like the way Turbine passes
> parameters in the URL (seems/feels like a "hack").

There are a number of reasons for using various parts of the URL (in
addition to or instead of the GET variables) to hold "parameters". One that
was mentioned earlier is the need to specify multiple URLs in a single
request, but that is really only a way of saying you want to be able to
provide multiple URLs as parameters to a request. That could be handled
using GET variables.

A different, perhaps more interesting, need is to manage forward caching.
Many forward cache mechanisms (such as Akamai's) use the existence of GET
parameters in a URL as a trigger to turn off cacheing! The assumption here
is that any GET parameters may cause dynamic changes to the served page
that render the cache invalid. In this context, several questions need to
be addressed by a web site designer to decide on a variable-passing scheme:

  1.) Is there a forward cache implementation in my setup or in
      someone else's down the line? Do I need to care about
      performance in this way?

  2.) Where do I want responses to be cahced? In my local server
      (e.g. Cocoon's cache)? In a forward cache? At the user's
      machine? All of the above?

  3.) Will my web site need to scale, and how can I manage this?
      Am I going to load balance across sessions or requests?

  4.) How do I manage or hide session data? How do I control
      authentication and authorization and hide resource handles?

  5.) What parts of a URL, if used in multiple requests, correspond to
      finding or building a fixed resource, what parts represent finding
      a dynamic resource, and what parts represent changing the state or
      contents of a resource?

Based on the answers to these questions, the designer may want to hide
parameters that control page contents but do *not* respond to other kinds
of dynamic activity (e.g. databases or quickly changing contents).

Finally, we should recognize that using path components as part of the
parameter set of a response is something we do all the time anyway. The
user-visible URL's three components (site, path, and GET variables) serve
different purposes, but they *all* can be treated as a combination of
specifications of how to find a resource or set of resources and
transformations to be applied to the resource.

Arbitrarily associating the path component of a URL with a file and
relegating parameters to the GET variables ignores virtual site design, CGI
choices, and non-file dynamic resources. There may not be a file behind the
request at all, but only a stream constructed in response to multiple
cycles of massaging all the components of a URL and calculating the
necessary response.

Stephen Zisk

Stephen Zisk                      MediaBridge Technologies
email:     100 Nagog Park
tel:    978-795-7040              Acton, MA 01720    USA
fax:    978-795-7100    

View raw message