While it seems people generally agree that some change is required here,
it also seems there are a good number of people who don't like
"resource". Here are the arguments against it:
- we're just switching one overloaded term ("model") for another
("resource"). Zope people tend to think of static files when they
think of "resource", Pylons folks already have confusion about
"resource" due to map.resource and other usages.
- Only the entire url represents a resource. Because
http://example.com/foo/bar is a valid resource does not mean that
http://example.com/foo is. Implying each segment is a resource would
be confusing.
Alternate suggestions:
- "traversal model"
- "node"
- "atom"
- "entity"
- "location"
- Some derivation of "sitemap"
OTOH, none of the alternatives really seem all that attractive to me.
The ones that have practical issues:
- "traversal model" is awful hard to put into APIs.
- "location".. this one is subtle.. traversal nodes
don't actually need to be "locatable" for traversal,
just for the APIs that construct paths and URLs from
them like model_url and model_path (IOW, the concept
of "location" only matters on the way "up" the graph
from a deep node, not downwards during traversal..
neither __name__ nor __parent__ is used during traversal
itself).
The ones I don't like because they're meaningless:
- "atom"
- "entity"
- "node"
The meaningless ones above aren't disqualified because they're
meaningless, though. I would just rather have something with some sort
of meaning.
This is why I'd actually still much prefer "resource" despite the chorus
of objections. Here's a list of objections and responses.
Objection
----------
- Only the entire url represents a resource. Because
http://example.com/foo/bar is a valid resource does not mean that
http://example.com/foo is. Implying each segment is a resource would
be confusing.
Response
--------
I'm not sure this is true. Yes, a particular URL will identify a
representation of a particular resource. But if you use traversal, each
of the nodes in the graph is a potential "resource" and can be accessed
potentially via some URL. The graph node exists to be traversed via the
path_info portion of a URL and, if your application uses traversal,
because of the way traversal works, the fact it exists means it indeed
will "have" a URL. Whether that URL returns some meaningful
representation or not doesn't really seem to be an issue. It doesn't
really seem to be that far away from some more common webby definition
of "resource" (I'm not even sure Roy Fielding would have a problem with
it ;-) ).
Please tell me how this is wrong.
Objection
---------
We're just switching one overloaded term ("model") for another
("resource"). Zope people tend to think of static files when they think
of "resource", Pylons folks already have confusion about "resource" due
to map.resource and other usages.
Response
--------
I'm apt to call this one a wash. Zope people can probably get over it.
Existing BFG/Pyramid users who also conflate "resource" with "static
file" can also probably get over it. I can't speak for Pylons or other
non-Zope folks, but other than the issues Mike raised (map.resource and
other Pylonsish usages of resource), it didn't seem like many non-Zopers
had an issue with it. And since Pyramid isn't really Pylons, and
because we're likely to implement "rest controllers" differently, I
think we can eliminate at least one competing Pylons definition there..
BTW, Restish (http://ish.io/embedded/restish/) also uses "resource" to
define nodes in its graph, although its graph is composed of cooperating
functions:
http://ish.io/embedded/restish/resources.html#so-what-is-a-resource
Fire away,
- C
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-de...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
