Ohh, I meant to respond to this earlier as well ...
Elias Torres wrote:
A few presentation notes that I think are applicable to our work:
http://simon.incutio.com/notes/2006/summit/schachter.txt
cool notes. some very good thoughts in there.
-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.
To be honest, I think the data model for tagging is going to be about
80% of the battle. And as it is with all things we may not get it
perfect the first time around, but we need to at least try and put some
decent thought into how we can model the data easily.
I think we should simplify as much as we can and focus on only what we
really need to make tagging useful. So I say we keep tags limited to
weblog entries only (we had talked about tagging websites) and we keep
them to a single word and case insensitive (all lowercase).
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.
I would agree with that, except that I think it's okay if we have a way
to turn it off and on. To allow someone to define a limited set of
feeds is probably more trouble than it's worth.
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.
I agree, you should just start a new branch from the current trunk and
merge your existing work back into that. My stuff is all committed, so
you can do this whenever you like.
-- Allen
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
