March 28th, 2001

apache on kenny

apache on kenny needs a beating.
more info later.
some of the dumb bitches I live with are driving me crazy.
must get out of here.
need laptop!

kenny's main problem seems to be that only 256 clients can be connected at once. in src/httpd/limits.h or something in apache there was:

#ifdef WIN32
#define SERVER_HARD_LIMIT = 1024
#define SERVER_HARD_LIMIT = 256

I changed 256 to 1024, then changing MaxClients to 512 didn't make "apachectl configtest" bitch, but it still seemed limited to 256. Is there an operating system limit too? Perhaps on the number of times a process can fork as a guard against fork bombs?

Anyway, I'm out. I'll try and fix this this afternoon.

Update, 11:30 am: I realized in class the Makefile for apache was probably screwed. A 'make clean' and full make fixed the problem. Now all 512 available children show up at /status
  • stipe

Applet Client

Brad made a comment yesterday about a good feature of a Win32 client being that it can be a standalone .exe with no real dependencies. Dependencies are admittedly a problem with a Java client since you need to have at least the JRE installed for anything to work.

Something that hadn't occured to me before but does now is the possibility of modifying my Java client to run as an applet. As the client stands now, this should be pretty easy. I imagine users on their own computers would probably stick to the available native clients, but it might be a good alternative to the web interface for people on shared systems.

Do you think an applet client would be useful? Should I bother doing the conversion?

Public test server

We need a public test server, open to all interested developers. I keep telling people, "just go look at the source." or "the source is open, go ahead and add the feature." but I realize it's not realistic to assume everybody has:
  • a few extra computers laying around.
  • system adminstration experience
  • free time
So, I'd like to somebody to maintain a test/development LJ server. Anybody have one already up and running and willing to open it up to whoever? I imagine many of you if you were to set it up would be installing it on your own unix box, in which case I wouldn't expect you to give everybody access. Or, anybody have extra crap hardware that we could put at Speakeasy? Any Pentium II with 128 MB of memory, few gig of diskspace, and a network card would work. Hell, I could build a test system for under a grand, but I'd rather not spend money if I don't have to.

Also, my goal for this next week is to get more documentation written. I also want to get the notification/subscription system working so we can follow lj_dev more like a mailing list, and not like a journal we have to keep checking. I want to do everything possible to "empower the developers" as Mark would say. :-)
  • piman

(no subject)

Preliminary DTD for storing LJ entries. I think we need to standardize on this (a DTD, not necessarily this one) across platforms and clients, it could make client transitions a lot easier, and have MyLJ tools work on any entry.

This one is based off Evan's work with the new Win32 client, with security stuff added (I couldn't find any examples of that in his XML files...)

I'm not the best XML guy, so I'm sure there's typos/errors/ways it could be improved.
goatee, cfl - looking

db suggestion

I was thinking about the recent issue where the database had to be manually touched to allow posts to show up and such. And Brad mentioned that it was 2/3 filled or something.

How about breaking the databases up by year... ie 2000 is one set of databases, 2001 is another, etc. that way it's easier to expand in the future... you can retire old entries without just deleting them from the database.. (ie entries 3 years old are archived and taken offline or something.)

Just thinking about what will happen in four years when we have terabytes of database entries for the 200,000 lj members at that time...

Also, piman's last post reminded me of something that's been bugging me about the comment interface... read about it at that link above...
  • Current Music
    Tangerine Dream - "Force Majeure"
agent smith

Time Issue Revisited

This was discussed awhile back, but has been on my mind for awhile. What's the current reason why we are keeping the current time system, or what was the decision?

For those of you who don't remember, if you view your friends page during the day switch over an issue happens with people in different time zones. You may end up with journal entries for Day X, then X + 1, then X, then X + 1 again. It's more of an annoyance factor then anything else. Also all comments are posted as PT. Kinda annoying for people in other time zones.

May 2 cents. Why don't we store the value as GMT, then per journal convert to some value specified by the journal owner. That way at least your journal is in your time zone, and the same with your friends page. These values can just be converted on the fly to prevent the DB from getting out of sync and not having more then one time zone specified.

I know people have also written things to figure out the time zone on your current computer and convert all the times on the page to that. Maybe stored in a cookie once you login? I don't know the right answer, but just wanted to see what progress and ideas others have.
  • Current Music
    (adams not funny)-better days
  • evan

win32 client design input

This was originally a mail to Mart, but I figure everyone can comment on it:

The basic problem is that Windows has two models for windows: dialogs, which contain controls, and normal windows, which contain menus, toolbars, and typically one child control.

LiveJournal needs to be a mix of both. We need a "subject" entry (and related metadata) and a "submit" button, but the window needs to be resizable and contain the edit entry.

Currently, I've been trying to use a rebar (the IE widget for containing widgets in the toolbar) to contain the "subject" bar. Then, I'd use a toolbar to contain the "submit" button. My other option is to write my own custom widget that handles the subject, security, and other post options. Outlook (for example) has a custom control in the "compose" window containing the "subject" and "to" fields.

Why I should use a rebar:
- Less custom code means fewer bugs and more time to develop other things
- Rebars are more common on Windows; greater consistency with Windows apps
- Rebars automagically support user-dragged reordering of child bars; while this isn't necessarily an important feature, it is something the users would like (one has already requested "docking"), and I don't want to implement on my own
- Resizing is handled mostly automagically

Why I should instead use a custom control:
- Maybe a rebar isn't the "correct" way of doing this
- The controls are very close together in a rebar, and I can't work around that without using a custom control
- Rebars can only contain one control per bar. This makes adding something like a "detect" button to a "current music" rebar a very serious task
- I can't, for the life of me, get the toolbar to position properly in the rebar
- The location of the "submit" option remains a big question, as does the location of the "additional post options" selector (see the LoserJabber UI screenshot for my inspiration)

I hate getting caught up in relatively unimportant details...
but this may be sorta important.
The basic problem is: Where does the "submit" option belong? Having buttons on windows is not common in Windows, and one of the most important rules to follow when trying to make a professional-looking application is "make it look like everything else".