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. 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. /<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. # /<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 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. 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 >> >> >>
