A few presentation notes that I think are applicable to our work: http://simon.incutio.com/notes/2006/summit/schachter.txt
-Elias David M Johnson wrote: > Hi Elias, > > Sorry about the delayed response. My comments below... > > > On Apr 18, 2006, at 1:19 PM, Elias Torres wrote: >> Let's have more discussion. I re-read the old thread and found this [1] >> to be David Levy's latest table definition: >> create definedtags as ( >> author_name char(32) >> entry_name (or id?) , char(128) >> user_tag_name, char(64) >> normal_tag_name, char(64) >> entry_date datetime >> date_created datetime ) >> I can start adding this to the code base for now or should I wait for >> more discussion? > > I need to read up on the old threads too. I'm not sure what to say about > this yet. > This is a tough issue we need to deal with a lot of attention. >From Joshua's presentation: **Put RSS everywhere you can** """Scaling: avoid early optimization. SQL doesn't map well to these problems - think about how to split up data over multiple machines. Understand indexing strategies, profile every SQL statement. Nagios or similar for monitoring. Tags don't map well to SQL. Sometimes you can prune based on usage - only index the first few pages for example. This keeps indexes small and fast.""" > >>> 3. There is no consideration put towards using tags in xml feeds. This >>> may be a good thing at first, but in the original proposal we talked >>> about having xml feeds based on tags, so I expect something. >> I'll get on it, sounds like must-have to me as well. > > I think we need to come up with a more complete proposal for supporting > tags. There are a number of parts and some are already addressed in the > existing tagging branch. > > 1 - Data model and back-end changes to support storing and querying via > tags > 2 - Changes to Weblog Editor page to allow entry of tags > 3 - Changes to Weblog Entry management page to allow tag queries > 4 - A tag cloud macro suitable for use in weblog pages > 5 - A tag cloud macro suitable for use on the front page > 6 - A Servlet to provide tag based weblog and site wide RSS/Atom feeds > 7 - A tag query page suitable for use on front page > > Most of those issues are impacted by the better URLs (coming soon) and > front-page enhancements we've proposed for 3.0. For better URLs, we need > to figure out how to use tags in weblog and feed URLs. And for the > front-page enhancements, I'm proposing that we turn the front-page of > Roller into a blog, so that it can be easily customized even at runtime > -- with tag filtered entry displays. I'd like to have a discussion about > how these things (better URLs, tagging and front-page blog) play > together and figure out how to map them to releases. > Right. Along the lines of better-URLs we need comment feeds. Right now we've hacked /rss/comments/* into the system, but if someone has a blog named comments, he's in trouble. We need to think about URLs soon because we can't be changing URLs all of the time. That's why we call them permalinks. ;) http://www.plasticbag.org/archives/2003/06/on_permalinks_and_paradigms.shtml > >>> 4. There is no consideration for performance or caching. Personally, I >>> would like to at least see some kind of documentation about how the >>> implementation plans to maintain good performance. If we haven't even >>> thought about that then we have a problem. >> I would like help on this area. What are your thoughts? > > I'm not too worried about the load of users querying tags from the front > page of Roller or within a single blog, but the idea of tag-based feeds > has me a bit worried. We need to be careful about allowing users to > subscribe to feeds based on arbitrary tag combinations. I'd like to > provide a way for a site admin to either 1) allow arbitrary tag feeds or > 2) define the specific feeds that will be supported. This is related to > the better URLs discussion too. I'm not sure this is an option. We just need to suck it up and make it work instead of "allowing" specific feeds, etc. >From Joshua's presentation: **Put RSS everywhere you can** """RSS important in del.icio.us, because it's a native way for people to access lists (of links). Put RSS everywhere you can. del.icio.us does way more RSS traffic than HTML or API stuff - partly because of poorly written readers. Understand the headers - especially if-not-modified.""" > > >>> 5. The UI isn't exactly well done. The tags page doesn't have its own >>> tab, so it looks weird when you are on the tags page and have the Main >>> and Planet tabs showing. And I don't believe the UI had any way to >>> constrain the tags view to a specific weblog. >> >> I'll work on making this a tab and think about how to view tags within a >> specific blog. Although I think that's a blog UI/template issue and not >> the dashboard area. > > This ties into the front-page blog proposal. If the front-page is a > blog, then we need a set of page models and/or macros to enable tag > queries, tag-filtered entry listings, tag clouds, etc. Right. I'm assuming if the front page is a blog, we'll need a macro (only allowed on that blog) to place the dashboard, right? > > >>> 6. No configuration options. There is no easy way to enable/disable >>> tagging support like we discussed and there are no controls for how the >>> tagging support will work if it is enabled. I think considerations like >>> items per page, max tag combinations allowed, etc are worth making >>> controllable. >> I'll take a stab at this. > > This is another thing that should be in a proposal. How configurable > does tagging need to be? I guess, I should be adding all of this to the proposal, right? > > >>> So, i think this is a step in the right direction, but i would like to >>> see things flushed out a bit more before we commit them to the trunk. i >>> would also like to continue a bit more of our discussion on the tagging >>> data model because i think that is the most crucial piece of the puzzle >>> for tagging. >> Makes total sense. >> Now a question from me.. Should I keep working on the same branch to >> apply these changes? or start with a fresh branch from the trunk? or >> wait until Allen checks in the new backend code? options, options > > I think you should still be working in a branch. You're going to have to > do some merge work to work in your existing branch, so perhaps branching > off of trunk now is better. I want to be clear on this. You are saying I should merge trunk with the tagging branch now so I'm up-to-date with trunk instead of waiting until later. I'm not sure if it'd be easier for me to get another tagging branch from you and just add the tagging code to it. Is Allen's new backend code in trunk? I think I want to wait for that. > > Now that Allen and I are mostly done with our 2.3 work, we're going to > turn our attention to better URLs and front-page improvements, so > perhaps we can starting having these discussions during the next week. > > If we can coordinate properly and you have time to devote to this > effort, maybe we can all work together on better URLs, front-page > enhancements and tagging in a 3.0 branch. I don't have as much as time as you guys do for this, but I'm keen on getting as much of our Blog Central features in the trunk so we don't have to maintain patches against the svn trunk. > > - Dave > >
