June 7th, 2001

  • weh

(no subject)

Might there be a way to make LJ more modular? It's just silly to have to recode your styles when you want to change the links at the top or do other modifications ... it'd be nice if it just called up a module for reused segments of LJ such as that.
  • zztzed

(no subject)

Last night I set up my own LiveJournal server just for the hell of it (yes, that is the sort of thing that I do for fun). I had a few problems with file permissions and I had to upgrade mySQL, but after that it worked pretty well, except for two problems:
1) It's pretty slow (of course, I am running it on a P200/MMX with 32MB of RAM and old, slow hard drives, and I'm not using FastCGI or anything, so that's more of an observation than a complaint)
2) There's no list of moods anywhere. I set a mood (specifically, "accomplished") on my first post and it just appears as "Current Mood: ". I've grepped around and all I see is the definition of the moods table and some SQL files for importing a few of the mood themes. Now, as I'm pretty happy with the set of moods from LJ, and I'm a lazy bastard, I don't really want to create my own mood list and I don't want to enter all the moods from LJ by hand. So, uh...what should I do?
  • jnala

Refactoring friends

The "Friends" concept is overloaded. It contains "people I'm watching", "people who may read my protected posts", "people who can post to this community", and "people I'm warm and fuzzy about and want a link to".

It is also inflexible. Some people want to be notified whenever their name goes on or off someone else's Friends list. Other people want to be able to reorganize their friends list without sending dozens of people into a tizzy.

Friend groups solve both these problems. Friend groups can be either public or private (not yet implemented, but support is there), and you can view or give permissions to different subsets of the total group of friends. The problem is this: No matter how easy it becomes to use friend groups, the default will still be your entire friend list, and that will still be easiest.

Put that way, the solution becomes easy. Give every user two friend groups with standard names. One is the default group for viewing one's own friends list. The other is the default group for allowing others to see your protected posts. These groups are undeletable, and are private by default. All new friends are added to them by default. The main friends list is used for providing the pool of friends which can be added to the subgroups, and for the warm-fuzzy-link purpose.

For many users, this will result in no visible change. Someone who doesn't want to mess with friend groups will continue to add and drop friends, and things will work as normal. For other users, it can provide significant extra ease of use and flexibility. It also opens the doors for future added features which would otherwise overload Friends even further.

Implementation is relatively straightforward. Add deleteable and add_by_default columns to the friendgroup table. Reserve a couple of bits for the systemwide groups, and turn them on for all existing friend relationships. Add the system groups for all existing users. Then go through the code and replace references to friends with references to friends in group [whatever].

Open issues:

What should the new system groups be called?

We only have one bit reserved; is anyone actually at the maximum number of friend groups, or can we go and reclaim a few more bits for this purpose and future expansion? We could expand to a 64-bit field or two 32-bit fields if necessary, but it'd be nicer to just grab a few more bits from the existing field. Someone with DB access, go run "select groupnum, count(userid) from friendgroup group by 1 order by 1" and tell us the results...