I recently read an article by cmdr_taco/hemos about the evolution of slashdot. One of the greatest things I took out of the article was about the processor load that it takes to generate dynamic perl pages.
The largest hit page on slashdot is the main page, which oringinally was dynamically created for EVERY view. Not long after they noticed perfomance issues they created a perl script to generate the home page on cront_tab once every 5 minutes. Apparently this cut the load on the server by some unreal amount (75%?).
How is this applicable to LJ? Is there a page on LiveJournal that is static? Even the static pages, like the homepage, are composed of BML which has to go through a perl interpreter for ever view. Would it help load to start using plain old boring html?
I'll probably get crucified for posting this here, but it's somewhat on topic... I've just charged myself to get serious about programming, specifically net related stuff.... can anyone point my in the right direction to get (re)started so I don't waste my time?
Idea... for a view of sorts.
This might end of being very complicated, and comes in two parts.
Create a alternate lastn view, that not only shows all of the entries I have posted in my journal, but also all of the entries I have posted in any shared journals or communities.
When a user adds a friend, allow them to add that person with an optional "Shared Posts flag" meaning that whenever this user posts anywhere (personal journal, shared journal, or community) it will show up on that users friends page.
Just a thought. Comments?
Well, if I am good, this will be posted to lj_dev with a little street sign picture. That means I have added picture and alternate journal support to the BeOS client.. If not, well, I still have work to do (but it will be in my journal anyway, so you wont care... :)
This one is easy...
Create an alternate view of lastn that allows the entries to be sorted by logdate as opposed to eventdate.
And.. a bit more difficult...
Give users the option to have their default page shown in logdate order or eventdate order.
These features are meant for people like me who tend to write something in a paper journal that they intend on writing in their LiveJournal eventually. They post 80,000 entries before they get around to typing the hand written entry. They want the date on the handwritten entry to reflect the date it was created, so they change the event date to be equal to that time. Now, the entry no longer shows up on the front of the lastn view, as they are ordered by eventdate and not logdate.
By allowing URL's like this /users/revjim?skip=10&order=log, this problem will be alleviated. In addition, if a user tends to post this way frequently, giving him/her the option to alter the default (when no order= variable is passed) makes it much easier.
Man... I am just full of ideas today.
Another thing. When replying to a comment (not a post) LJ does not show you the comment you are replying to. When replying to a post (not a comment) it does.
Would it be possible to show the comment that is being replied to above the comment Form? Due in part to the email world, I am so used to having the message I am replying to available to me as I am writing my reply, that this becomes somewhat of a nuisance.
In addition to the calendar page, there could be some sort of index page that would be a list of x entries... it would show the date/time, the subject (if any), and the first y characters/words in the body of the entry... it would help for people to go back and search for a specific entry in lengthier journals.
Hey, now that we have the spare CPU cycles, can we get as many clients as possible running over an SSL connection?
Granted, this probably won't work so well for the web client, because of that funky cert auth dialog box, and the general knowledge base...
Just a lil bit-o paranoia.
By the by, how's the backup situation for the livejournal servers and their configurations? I don't recall hearing much about this.
Lil' more paranoia :)
BTW, what are the possibilities of localized LJ image mirrors? Have the server point to images hosted closest to where the user says they are, and have some volunteers with too much bandwidth shove up a crappy thttpd server mirroring the images, or somesuchsomething.
My plan is to go running in 20 minutes, come home, then start releasin' some semi-complete and complete code for whoever feels like it to critize, analyze, fix, complete, whatever. Most the code will be licensed under the LGPL, with the exception of BML, which is already released under the GPL ... BML hasn't been released in ages, and quite a lot has been changed around. After releasing BML, I also plan to start documenting it a lot better.
Note that I won't be releasing cgi-bin/*, htdocs/* ... just sections from random spots that I think will be useful to others also, and that I feel people could start helping with already.
Don't think that what I release tonight is the end of the code. In the future I'll release more and more of LiveJournal, but there are still a lot of licensing questions in my mind, and I need to research that more.
Yet another idea....
Via the Meta-Data system for journal entries, allow users to specify a "category" for each journal entry. Then allow the filtering of lastn by category, just as the friends page can be filtered by friends group.
As an added bonus, allow users to define a default category to automatically filter their lastn page by.
This will allow me to distinguish between a "poetic" entry... a "short update" and a "lengthy rant on the stupidity of politics".
Of course, once this feature is active, I can think of a bazillon more things to do with the data once we have it. Just as a taste... a user could provide a link on the top of their journal to "poetry", show casing that users poetry. Or "photography", should a user be into that sort of thing, to allow visitors to see ALL of that users photography.
Then... eventually... with the new style system, perhaps provisions can be made to allow multiple lastn styles, so that my poetry page can look different than my short updates page. Or, provided this functionality is present in the new style system, allow me to show my most five recent "short updates" at the top of the page in a box, followed by the one last "lengthy entry". The possibilities are endless. And besides... having meta-data is just plain cool.
I know building these sorts of things takes time. However, if we decide to go forward with this plan, I strongly suggest adding the meta-data field before allowing users to filter by it... that way, while the feature is being coded, journal users can be categorizing their journal entries for use when the feature is finished.