Viewing a list of all tags?

[cheungpat]

Hi,

Is there anyway to view a list of all tags?... except exporting
bookmarks and running it through a python script, that is.

I noticed there is a discussion earlier in June about this (list of
tags). Though it geared towards providing autocompletion in the
bookmarklet form.

Having a list of all tags is helpful because the I find a bookmark by
tags, and if the tags aren't in the top tags list I wouldn't find it.

The trivial way to implement this is to display all tags like a huge
tag cloud. Any other ideas? Anyone needing this feature also? (I could
keep using my python script.)

http://groups.google.com/group/pinboard-dev/browse_frm/thread/3c8d3d472cc977fd/322002e0ed7e7c97

[maciej]

I was thinking of implementing this the same way delicious does - by
enabling a tag list view filterable by count (1,2,5,all tags). I
had this nearly finished but for some reason it fell by the wayside;
I'll see if I can get it pushed live today.

> http://groups.google.com/group/pinboard-dev/browse_frm/thread/3c8d3d4...

[cheungpat]

This is much better than I have hoped.

It seems "all tags" doesn't show private tags (tags beginning with
dot), while the "top tags" does show some of them.

kuen

[maciej]

On Oct 28, 4:35 am, cheungpat <cheung...@y03.hk> wrote:

> It seems "all tags" doesn't show private tags (tags beginning with
> dot), while the "top tags" does show some of them.

I turned off private tag view until I could make sure that the privacy
settings on tag lists were working properly. They should show up
later today or tomorrow after I finish testing.

[Lenny Domnitser]

Ah, glad to see all those rare tags. Could they be added to
autocomplete as well?

Boo!
Lenny

[maciej]

The issue with autocomplete is that right now it works by downloading
a list of tags and doing completion locally in javascript. This is
fine for a couple of hundred tags, but people with larger tag
collections (in other words, nearly everyone on the site) would end up
having to download a large JSON file of all their tags every time they
wanted to add or edit something. I think this would add more suck
than it subtracted.

The right solution is to do tag completion on the server side, but
this will require a fair amount of work and testing, so it may be a
little while longer before I can make the change.

[Lenny Domnitser]

On Nov 2, 10:45 am, maciej <mceglow...@gmail.com> wrote:
> The issue with autocomplete is that right now it works by downloading
> a list of tags and doing completion locally in javascript.  This is
> fine for a couple of hundred tags, but people with larger tag
> collections (in other words, nearly everyone on the site) would end up
> having to download a large JSON file of all their tags every time they
> wanted to add or edit something.  I think this would add more suck
> than it subtracted.
>
> The right solution is to do tag completion on the server side, but
> this will require a fair amount of work and testing, so it may be a
> little while longer before I can make the change.

I thought Delicious does their completion client-side too (no time to
explore this now). I think with proper caching you're really not using
much bandwidth.

* Tag lists don't need to be super fresh, so repeated requests within,
I don't know, 6 hours or something, can just use their old copy and
transfer 0 bytes. (See Cache-Control.) What some folks do with
JavaScript and CSS and such is have the file never expire in the
cache, and change the URL when the file changes.
* Tag lists that don't change between requests can be truncated to
just HTTP headers. (See conditional GET and the Etag header.)
* Even when the tag list must be downloaded, JSON's real compact, and
it can be effectively gzipped.
* Probably unnecessary, but you could partition large tag lists across
several files so that only changed sections have to be downloaded.
Getting into really unnecessarily fancy territory, there could be 2
files: a stale tag list and fresh deltas.

Of course I don't have the stats on how big some of these tag lists
are, but a few KB of JSON once in a while seems pretty small compared
to the dynamically generated HTML Pinboard already serves. NB: server
side completion has lots of overhead and can't realistically benefit
from caching, so it's probably overkill until a tag list gets huge.

tl;dr - Cache-control and conditional GET should remove most of the
bandwidth associated with completion.

[maciej]

On Nov 3, 10:41 pm, Lenny Domnitser <ldr...@gmail.com> wrote:

> I thought Delicious does their completion client-side too (no time to
> explore this now). I think with proper caching you're really not using
> much bandwidth.

Your answers assume that browsers do decent cache management, which is
not true. Something like one in five page loads are cache misses
(Yahoo claims), so the user experience has to be decent even with an
empty cache.

It may well be that even with 10k tags it will still feel snappier to
just download the tags and do autocompletion locally in javascript,
but that will require testing.

My biggest priority is to keep the 'just save this bookmark' workflow
from getting mushy. Half the reason I stopped using delicious was
because the popup would take forever to load.

[A J]

2009/11/3 maciej <mcegl...@gmail.com>:

> My biggest priority is to keep the 'just save this bookmark' workflow
> from getting mushy. Half the reason I stopped using delicious was
> because the popup would take forever to load.

fwiw, I vote for this too; this is something I really like about pinboard.

-Amy