December 16th, 2003

style=mine Issues

Lately, I have been trying to write patches that would give consistency and continuation for style=mine in both style systems. That is, if style=mine is set and you do some action, it should behave the same in both styles systems, and it should reserve style=mine when it is intuitive to do so.

This includes:

There is one case timwi seems to have written a patch for earlier that never got dealt with, which talks about respecting style=mine when previewing a comment, and another reported by crschmidt that talks about the inconsistency of style=mine among free and paid accounts. Those two cases, although related, defer from the above one in the fact that it's not an issue of preserving style=mine but starting it. They are, however, related.

There are more cases I have been thinking of:

  • When adding a memory, it would be a good idea to link back to the post. I do not know a good reason for it not to be done, and I think it should also preserve style=mine. I will write a patch for that in case it's just not there because nobody has found it worthwhile to do.

  • One other very important issue is that of permalinks, those are links that are available in comments and link to them. I have also included preserving them in one of the above patches, however, pinterface suggests that permalinks shouldn't have style=mine preservation. So what does everybody think is the right thing? The problem is that S2 uses the permalink url for collapsed threads, so if we are going to separate them, all S2 styles would have to be edited in order to include the style=mine preservation.

One more note, to keep the url format clean (style=mine at the end, for instance), I had to write a new version of talkargs that smartly puts anchors at the end. The bugs I mentioned above depend on it.

Finally, I want to ask, does anybody know of more cases where style=mine preservation currently fails?

So, opinions are welcome, and of course the word of those who have the power to decide would also be appreciated. Thanks! trimming

Over time people keep adding crap to and the time it takes to run a simple script which requires keeps increasing.

Currently (on my dev machine), it takes 0.690 real seconds just to parse and load dependent modules from (this is after warming caches unti the number stabilizes)

I experimented with trimming, removing non-core libraries:


real 0m0.690s

remove ljcom modules: geo::ip, cracklib, inline

real 0m0.652s

remove modules: ljlang, poll, feed, links, cleanhtml, htmlcontrols

real 0m0.588s

remove mail stuff from ljlib: MIME::Lite and Text::Wrap

real 0m0.547s

remove phonepost (and thus Blob) from ljlib:

real 0m0.512s

remove paylib from ljcom:

real 0m0.329s

And this is all without moving any functions out of For instance, LJ::send_mail() could move to a new LJ::Mail package, and that package could also require Mime::Lite and Text::Wrap.

We did this a while back, but it's time to trim it all again. (scary, though)

Documenting LJ:: variables

When captcha first got added to CVS, colin made the post at , in which Brad described how to set up a blob server. However, so far as I can tell, this isn't documented anywhere.

I went to go write a patch for documenting it, but in grepping through the documentation, I couldn't find where the ljconfig variables actually go. The other information ( ) is there, but the variables part ( ) doesn't seem to be. The XML seems to call some kind of function ( &lj.install.ljconfig.vars.gen; ) but I can't figure out what that links back to.

Any help?
hat, potato, spud


Hi all, this is just a brief introduction since I've just joined.

I've been developing for about five years now in a variety of environments. I'm very interested in web services and distributed systems integration issues.

I'm sure you'll be seeing more from me in the not-too-distant future.