On Jan 7, 2005, at 10:30 PM, Peter Hunsberger wrote:
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.
Hmmm... This is a question of semantics. To me the app is the only resource. Because I use the http protocol I am constrained as to how I issue commands and pass arguments. As a result I use constructs that appear to be URIs but in reality are just an awkward translation to something that looks like a URI. This does not diminish the problem but explains why it exists.
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?
Sorry, I just missed it. I'm glad we agree.
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:
Probably.
weather is a published resource, it's not an application.
This was too simplistic an example with out the details. I should also not have used an existing site. The point was a single application/resource can be accessed by two distinct URLs and changing URLs is unsettling to a user.
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,
Of course. And this is where problems in structuring a sitemap arise.
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.
What else do you have? This is pretty much it X 1000s. An application consists of its commands and queries. Each may have parameters. The problem is mapping the commands, queries and parameters to something that is a valid URI. Your sitemap can only do so much. With the advent of flow there is a very direct way to map public URLs to commands and queries. If you want to simplify (though not shorten) your sitemap use flow and match using a hierarchical menu like pattern (
<map:match pattern="patients/edit">
<map:call function="editPatient"/>
</map:match>
).
I realize that everything is not this simple. Many problems arise from technologies that have been supplanted by flow. Prior to flow there was a tendency to use the sitemap as the application controller. Using it as such probably leads one to much more inventive URI designs.
You've got to allow for variations on authorizations, error handling, timeouts, resumed sessions, etc.
These do not have to be public URLs. All of these things are internal to the application. If you are providing your users with URLs for these things you should ask yourself if there is a better way to handle this.
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.)
As always, it depends on the problem space. ;-) There is not one best way and thats why implementing the sitemap according to the "best way" to design your URL space is probably a bad idea. I do find the idea of a tree structured sitemap appealing (even though it works nicely with my "best way" :-O).
Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to worry about answers."
- Thomas Pynchon Gravity's Rainbow
