Opened 14 years ago
Last modified 9 years ago
#183 closed enhancement
tag clouds — at Initial Version
| Reported by: | Caleb Davis | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | programming | Keywords: | |
| Cc: | Parent Tickets: |
Description
This is another rollover from `#360 </issues/360>`_, but it got
left behind somehow. A tag cloud is a dict-like object containing
{'tag-name':frequency-of-use,...}. It's fun to have them to see all
the tags that people are using publicly on an instance.
Where would we display these?
- instance home page - all users, processed media
- user's profile - user's processed media
- [BONUS] - arbitrary collection (/tags/bunnies) Open questions:
- Should we use MapReduce?
`http://cookbook.mongodb.org/patterns/count\_tags/ <http://cookbook.mongodb.org/patterns/count_tags/>`_
The alternative would be to write tags to a text file and do
sort tags\_text\_file \| uniq -c
or do it completely within python \* Should we use celery?
Generating tag clouds shouldn't slow page renders. Thoughts:
do it with python if you're using MapReduce since, if MapReduce
gets too slow, you just add more processors!
if it 'takes too long', then use celery
- How often do we update the clouds? Thoughts included:
not during a bulk upload
- How do we store these tag cloud objects? If we're not rendering
them on the fly, then they should be in some kind of cache.
Thoughts:
user['tag\_cloud'] = dict
associate the cloud with the route. something like -
{'/':'instance\_cloud.txt','/u/user1':'user1\_cloud.txt','/tags/bunnies':'tags\_bunnies.txt'}
Note:
See TracTickets
for help on using tickets.
