right now, the url of a entry in a clustered journal gets an url like this:
www.livejournal.com/talkread.bml?journal=
while unclustered journals still have the old style urls like that:
www.livejournal.com/talkread.bml?itemid=
a) use numerical id of a journal/user instead of the name ?
journal/user names are not unique over time ..
what if a username is deleted and later reused by a new user ?
or some user decides to pay the fee for renaming their account ?
since the numerical ids of users are unique and dont get recycled, i think they should be used instead to avoid the problems mentioned above.
since comparing integers is faster than comparing strings, the db index tree operations might be a bit faster for integer keys than for string keys. so it might be faster to have only numerical ids for the entries. i dunno how much faster that variant would be, but im sure it wouldnt be slower.
b) one more option for new style talk* urls :
if the numerical id of a journal would be used, then we would have two numerical ids (journal number + entry number). besides the already discussed options of how to put the two ids in one url, there would be the option of using some arithmetical transformation that calculates one combined id from the journal id and the entry id (e.g. f(jid,eid) := ((jid << 32) + eid); or some even smarter formula, as long as it is a bijective function).
maybe in some spots of the code, the combined id (= f(jid,eid)) could be used as db key, instead of the two indivual ids. maybe that would lead to some other speed improvement.
( bijective function means that it is possible to calculate jid and eid from their combined value f(jid,eid) )
c) human readable talk* urls :
one advantage of the current new style talk* urls is that they show the destination journal they point to in a form that is readable by the human user. that advantage would get lost if option a) or option a) and b) would be implemented. but it would be possible to compensate that loss by adding some human readable translation as html link title, e.g. (assuming only option a) gets implemented):
<a href="www.livejournal.com/talkread.bml?j=0which would create a link title like e.g. "JohnDoe's 7th entry of 2002-02-07" or something ..
certain browsers (e.g. internet exploder) display these link titles as tool tips when youre hovering with the mouse cursor over the link.
check your browsers behaviour by hovering (dont click !) over this link pointing to itself ..
d) making option c) customizable in the style definitions
if we are really bored, the link title string could be added to the style definitions. that would allow funny shit like:
<a href="..." title="in his %%x%%th rant on %%dayshort%%, %%mon%% %%dth%% in the year of the lord %%yyyy%%, our self proclaimed prophet %%username%% has spoken these wise words ... ;-P">.. just as the comment links are customizable now ..
well, forget about option d), its just some completely unnecessary, silly fun feature .. ;-P
and option b) and c) might be nice to have, but are not exactly necessary either ..
but i think option a) should be considered - or is that problem solved somewhere else already ?