cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <peter.hunsber...@gmail.com>
Subject Re: [RT] Escaping Sitemap Hell
Date Sat, 08 Jan 2005 04:30:11 GMT
On Fri, 7 Jan 2005 17:38:35 -0600, Glen Ezkovich <glen@hard-bop.com> wrote:
> 
> On Jan 7, 2005, at 1:43 PM, Peter Hunsberger wrote:
> 
> > On Fri, 07 Jan 2005 14:28:06 -0500, Stefano Mazzocchi
> > <stefano@apache.org> wrote:
> >>
> >> See? the problem is that you are partitioning the matching space with
> >> URL matchers... I strongly feel that most of the problems that Daniel
> >> (and you) are outlining will just go away if you used non-URL
> >> matchers.
> >
> > Although I agree that 90% of the problem seems to be a matcher issue
> > I've got to ask; what would the matchers be matching on if it's not a
> > URL?  I have a couple answers, but I'd like other opinions...
> >
> > It seems to me that Daniel might be coming at this from a mostly
> > application POV.  If so, for such cases, I think you can't _always_ be
> > quite as dogmatic about how a URL is structured; for many apps there's
> > little to no exectation of long term URI persistance/repeatability.
> 
> I don't see this. The application is the resource and it is the
> application that should have a unique identifier. If the application
> allows a user to perform multiple tasks you may want to consider each
> task a resource. 

An app may be 1000's of resources.  The issue is how to find a
rational way of getting 1000's of unique identifiers.

> The persistence of the URI in general is not that
> important from a users perspective since the URI identifies a resource
> that might be reachable from multiple URLs. What is important is that
> the URL that a user uses to reach an application persist and not change
> as long as users may use the application. 

Umm, wasn't that my point?

> We may not expect to see
> identical results each time we access http://weather.com/neworleans but
> we do expect to get the current weather forecast for New Orleans. If
> weather.com switched the URI/L to http://weather.com?city=neworleans,
> as a user I would be perturbed to say the least.

You're missing the point: weather is a published resource, it's not an
application.   Consider something like a Web hosted SFA app, something
where you need work flow. The hard point isn't getting to the app, the
hard part is partitioning the app.  You've got lots' of orthogonal
concerns (and I mean lots). URI, scheme (protocol), and request
parameters (among others) all give you ways of attacking various parts
of the problem, but when you start hosting 1000's of different app
spaces on the same machine the issue isn't as trivial as
scheme://host?couple-of-parms.  You've got to allow for variations on
authorizations, error handling, timeouts, resumed sessions, etc.

> As far as dogmatism and URL structure goes, you can always be dogmatic
> in the way you structure them. ;-)  The problem with dogmatism is that
> it does not always lead to the best solution for a given case. Then
> again sometimes it does.

And that's this issue Daniel's worried about: what's the best
solution.  (However, I'm not completely sure for what problem space.)

-- 
Peter Hunsberger

Mime
View raw message