February 9th, 2002

S1 & Clustering

We're now moving users to clusters 1 & 2 automatically. Cluster 3 won't be setup until load's down on "cluster 0" enough to steal two servers from it.

Now that we're moving tons of people to clusters, more and more S1 issues are going to come up.

The problem is styles that do unsupported things like linking to editjournal.bml, memadd.bml, etc, etc...

So basically, we need to make some new info available in S1 so people can fix their links.

Somebody come up with a good proposal and post it here. I'm thinking something along the lines of %%itemargs%% which is either "journal=foo&itemid=3535" or "itemid=23434".

Along with avva's patch to make editjournal.bml take an itemid*256+anum, the above should work.

But somebody think it all out.

/doc/find CGI script

Please read this if you're interested in the design of the new documentation system, or if you have expertise in FastCGI or non-Apache servers like IIS.

Earlier today (talkread.bml?itemid=22974104), I introduced a plan for assigning canonical URLs to new LJ documentation. Under this plan, a document which could be requested directly as
will normally be linked to (from outside the documentation system) using the less specific URL
The redirection is performed by a simple CGI script which will later be enhanced to do various things like selecting from multiple document formats.

I have no experience with IIS or servers other than Apache. To avoid future porting difficulties, it would be helpful if people familiar with IIS or other servers could comment on whether the plan I've described would be more difficult to implement on other servers.

Collapse )
press your luck
  • colin

deleting communities

I know bradfitz and others don't like the idea of communities being deletable. Would it be feasible to implement an objection system? This would be sort that solves the "it would suck if a popular community got deleted" problem but still allow communities to be deleted in some way.

When a community is deleted, the community's views would be replaced by a page that notifies the user that the community was going to be deleted, and if they objected to the deletion to click a box and press a button. If x% of the members of the community objected, it would immediately be reactivated. If, after y days the necessary number of objections haven't accumulated, the community is marked for deletion.

Of course, this raises a few problems. First and foremost, if the maintainer of a community really wants it deleted, that person can just delete the community over and over until the members finally get so annoyed they don't vote to keep it. I think the best solution to this would be do not allow another deletion attempt for a (fairly ample) amount of time.

Also, what happens with communities that have only one or two members who keep objecting just to piss off the maintainer? There should be a lower limit (probably when x% of the users is at least 3 or 5) on when this becomes necessary. If the minimum number of members is not met the community can be deleted freely.

My main issue with deleting communities is that the Internet and permanence are not the best bedmates, and the namespace for communities and users are not separate.

Collapse )