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.
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.
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.
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.
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?
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.
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.
- Dave
