good questions. comments inline below ...
Elias Torres wrote:
Basic Url Overview:
* /<weblog>
* /<weblog>/entry/<anchor>
* /<weblog>/date/<YYYYMMDD>
* /<weblog>/category/<category>
* /<weblog>/tags/java+frameworks+spring
* /<weblog>/feed/<flavor>
* /<weblog>/page/<page link>
* /<weblog>/resource/<uploaded file>
* /<weblog>/search?q=<query>
Language Support (<lang> is a 5 char locale identifier like "ja_JP"):
* /<weblog>/<lang>
* /<weblog>/<lang>/entry/<anchor>
* /<weblog>/<lang>/feed/<flavor>
* /<weblog>/<lang>/page/<page link>
* /<weblog>/<lang>/resource/<uploaded file>
* /<weblog>/<lang>/search
I like all of the above. I think they are good. I like entry because
it maps to Atom entry. I don't like resource as much though. I think
that everything is a resource so why single "files" or "attachments"
or "media" etc.
I just chose "resource" because that is what we call it now, but what
you said makes a lot of sense. I like "file" or "media" from your
suggestions, with "media" being my favorite.
Entry Collection views:
* /<weblog>/date/<YYYYMMDD>?page=1
* /<weblog>/category/<category>?page=1
* /<weblog>/tags/java+frameworks+spring
I don't like ?page=1 on the first ones. I think in the proposal you
said you wanted to limit path urls which I think it's great. Now,
since we have the ability of doing paging for each one of those path
URLs using just /weblog?cat=... why not remove ?page=1 from the path
based ones. I just think it's cleaner.
I'd go either way on this one. My hope is that we can promote the path
based urls via the macros, etc and not really expose the query param
based urls too much. That's why I wanted to make the path based urls
pageable on their own.
However, I suppose there is no reason not to make the path based urls as
clean as possible and then point to the query param urls any time
additional functionality is needed.
/<weblog>?category=<cat>&date=<date>&tags=foo+bar&page=1
Fair enough.
# /<weblog>/entry/<anchor>
# /<weblog>/<lang>/entry/<anchor>
I'm a bit concerned with overloading the entry URLs for POSTing both
trackbacks and comments. Let's look at Atom, they separate editURIs
from reading URIs. I think the main reason is scalability. I know
conventional wisdom gets challenged every day, but if Atom separates
the two, why do we the opposite and worse yet for doing something
other than actually editing the entry itself. What about the static
case? We couldn't split as easily static content from servlet
requests.
hmm, I still prefer that we not do separate urls for posting comments
and trackbacks. I think it keeps the urls much nicer in a variety of
ways ...
1. users never see a special url to post to (/comments or /trackbacks)
which keeps the url space cleaner
2. it helps a lot to actually be posting that data to the real permalink
location because users cannot mistakenly try doing a get request on a
url which only allows posting. right now when you post a comment your
browser will go to /roller/comment. i think that is bad because it
doesn't really indicate the page they are on and creates the potential
for them to mistakenly bookmark or reuse that inappropriate url somehow.
3. static sites are always going to have to deal with how to handle the
posted content and i think that is a problem for them to solve.
# /<weblog>/feed/<flavor>
# /<weblog>/feed/rss?cat=<cat>&excerpts=true
# /<weblog>/feed/atom?cat=<cat>&excerpts=true
How about:
/<weblog>/feed/<flavor>/(tag|cat)/<value>
/<weblog>/feed/atom/tag/java+frameworks+spring
i am actually against this one because in my opinion feeds do not need
to be especially nice urls. these aren't urls that people are going to
be traversing like they do with webpages, so i think that convenience is
the better approach here. plus, 90%+ of feed requests are just going to
be for the root feed, which will still be path based (/<weblog>/feed/atom).
if you look at some other sites i think you will find the same thing,
they don't spend as much effort making their feed urls pretty because
feeds are mostly meant to be consumed by other computers, not people.
Overall, I would like to be more consistent since in some places we
use query parameters in others we cram it into the path. I think a
good point from the file extensions is that dynamic pages (i.e. query
parameters) are less likely to be indexed. Maybe that'll help us
decide what shouldn't get parameterized using ?param style and what
should.
I agree, we should definitely be as consistent as possible and I think
we are doing a pretty good job of that.
* /<weblog> (query params)
* /<weblog>/entry/<anchor>
* /<weblog>/date/<YYYYMMDD>
* /<weblog>/category/<category>
* /<weblog>/tags/java+frameworks+spring
* /<weblog>/feed/<flavor> (query params)
* /<weblog>/page/<page link> (query params)
* /<weblog>/resource/<uploaded file>
* /<weblog>/search (query params)
assuming we agree to not allow query params in the single criteria entry
collection views (/date/*, /category/*, /tags/*) then we only allow 4
urls which allow query params and in all of those cases i think they are
warranted.
-- Allen
Just my opinions,
-Elias
On 5/8/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
This discussion seems to have wound down, so I have collected what I
believe has been the general consensus on the various discussions about
the URL structure and updated the proposal ...
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_NewUrlStructure
I'd like to go ahead and call for a vote of approval on the proposal so
that I can move forward and begin working on the next step, which will
be to provide a proposed implementation of the new url structure.
+1 from me on the current proposal.
-- Allen
Allen Gilliland wrote:
>
>
> David M Johnson wrote:
>>
>> On May 3, 2006, at 10:30 PM, Allen Gilliland wrote:
>>>> Dave: Also, I don't understand why we need a date in the entry
>>>> permalink.
>>> We don't *need* it, but if it helps make the urls more functional
>>> then it is worth considering. If you look at other blog sites like
>>> typepad, livejournal, and blogger, they all do it that way. That
>>> doesn't mean it is right of course, but it's worth thinking about.
>>
>> Since our "anchors" are unique across an entire weblog, there's no
>> need for date info the permalink URL. It doesn't add any
>> functionality. It just makes the URLs longer. And, as you mentioned,
>> it could result in permalinks that change when the date changes.
>
> Right. I wasn't saying that we need that stuff in the permalinks for
> any reason. I am merely asking the question, "other big blog sites do
> it, so is there a reason we should too?"
>
>
> *snip*
>
>
>>
>>> i have wavered back and forth about wether or not to allow these path
>>> based versions of the entry collection views and i think by biggest
>>> hang up is on the issue of url redundancy. what we could do is offer
>>> path based urls for entry collections that only specify a single
>>> criteria, like date, category, etc. then we could continue to allow
>>> the weblog homepage to support an arbitrary number of url query
>>> params to allow for views that refine by multiple criteria. i.e.
>>>
>>> /<weblog>?date=<YYYYMMDD>&cat=<category>&tags=<tags>&page=3
>>>
>>> but the software would promote these urls ...
>>>
>>> /<weblog>/date/<YYYYMMDD>
>>> /<weblog>/category/<category>
>>> /<weblog>/tag/<tag>
>>>
>>> none of those urls would allow for restriction by an additional
>>> criteria.
>>
>> Ah... OK. Now I see where you're going. That "offer path based urls
>> for entry collections that only specify a single criteria, like date,
>> category, etc." restriction is a good thing.
>
> Right. So the idea is that most of the time users aren't going to need
> to view entries constrained by multiple criteria, so we can provide
some
> nice, short, simple, path based, and easily indexable urls for these
> views. Then for the more rare cases where someone does want to view
> based on numerous criteria then they just have to use the query
> parameter version.
>
> As far as I can see the only possible downside is that we can end up
> with 2 urls to the same page ...
>
> /<weblog>?cat=<category>
> /<weblog>/category/<category>
>
> None of the software will promote the query param version, but
> technically it will be there and work. That's probably not that big of
> a deal though.
>
> -- Allen
>
>
>>
>>
>>>> Then use a similar structure for "custom" pages, since they also
>>>> need date, category, etc.
>>>> /<weblog>/page/<page-link>?category=<cat>&page=1
>>>> /<weblog>/page/<YYYYMMDD>/<page-link>?category=<cat>&page=1
>>>> /<weblog>/page/<YYYYMM>/<page-link>?category=<cat>&page=1
>>>> /<weblog>/page/<YYYY>/<page-link>?category=<cat>&page=1
>>>
>>> I think for the user defined pages that we should stick purely with
>>> query params mainly because we have no reason to suspect that user
>>> defined pages are mostly concerned with those criteria. I think we
>>> will want to allow the user defined pages to have access to any query
>>> params they want to use.
>>
>> That works for me. I think the calendar tag models, which are both
>> category and date aware, can be easily rewritten to support this
>> scheme and in weblog and custom pages -- just as they do now.
>>
>> - Dave
>>
>>
>>
