On Fri, 7 Jan 2005 17:38:35 -0600, Glen Ezkovich <[EMAIL PROTECTED]> wrote: > > On Jan 7, 2005, at 1:43 PM, Peter Hunsberger wrote: > > > On Fri, 07 Jan 2005 14:28:06 -0500, Stefano Mazzocchi > > <[EMAIL PROTECTED]> 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
