?

Log in

No account? Create an account
LiveJournal Development [entries|archive|friends|userinfo]
LiveJournal Development

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

January 17th, 2001

Thoughts on dynamicly created static pages [Jan. 17th, 2001|12:10 am]
LiveJournal Development
lj_dev
[itchi]
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?
link10 comments|post comment

fyi [Jan. 17th, 2001|12:48 am]
LiveJournal Development

lj_dev

[hap]
Hi, I'm Heather, and I've realized the error of having a username composed of three letters commonly written together while searching for my comment in the talent pool post. Currently I work as a fulfillment developer for an e-commerce company. I'll keep this short and only mention those things that might be of use to LJ.

I have a lot of experience with: perl, java, c++, SQL, XML, various *nix and windows OSes, and various script-y languages.

I have some experience (mostly of the sort described below) with: HTML, XSLT, ASP, vb...and probably more I'm forgetting.

With a little documentation (or time) I can figure out how to do what I want with just about anything, as long as it's possible.
linkpost comment

Trust system [Jan. 17th, 2001|04:38 pm]
LiveJournal Development

lj_dev

[bradfitz]
Evan and I have been discussion setup a web of trust system on LiveJournal for awhile.

We need to do something like this.

Imagine: instead of being able to say, "Only my friends can post", you can say, "Only respectable non-assholes." can post.
link3 comments|post comment

I wanna be a developer when I grow up! [Jan. 17th, 2001|05:20 pm]
LiveJournal Development

lj_dev

[colin]
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?
link6 comments|post comment

(no subject) [Jan. 17th, 2001|05:25 pm]
LiveJournal Development

lj_dev

[revjim]
Idea... for a view of sorts.

This might end of being very complicated, and comes in two parts.

Part One:
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.

Part Two:
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?
link3 comments|post comment

Do I Suck? [Jan. 17th, 2001|05:28 pm]
LiveJournal Development

lj_dev

[grahams]
[mood |curious]
[music |Susanne Vega - As a Child]

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... :)
link5 comments|post comment

(no subject) [Jan. 17th, 2001|05:30 pm]
LiveJournal Development

lj_dev

[revjim]
Another idea....

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.

Comments?
link1 comment|post comment

(no subject) [Jan. 17th, 2001|05:37 pm]
LiveJournal Development

lj_dev

[revjim]
Idea for a paid user feature....

Automatic website caching.

Here is how it works. When I post in my journal and link to a website... what if that website changes and the content I am referencing is no longer available. A special entry tag could be created so that URL's would look something like this:

<A HREF="cache[http://www.msnbc.com/]">look at the news</A>

This would tell the LiveJournal server to go get that page, and any images on it... and store it for archival purposes. When the event is rendered (in a friends view, or a lastn view, or wherever) the cache[.*] portion would be replaced by a URL on LiveJournal servers that would cause a framed version of that page to appear. The top frame would state that the page was cached on XYZ date for user revjim and give the actual URL to the website. Then... in the lower frame. The cached version of the page would be shown.

Some additional measures could be taken to allow caching multiple link levels, offsite links, etc etc etc. The amount of the page that is cached is someting that will need to be worked out... but the concept is there.

Comments?
link7 comments|post comment

(no subject) [Jan. 17th, 2001|06:42 pm]
LiveJournal Development

lj_dev

[revjim]
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.
link4 comments|post comment

another idea [Jan. 17th, 2001|06:59 pm]
LiveJournal Development

lj_dev

[colin]
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.
link5 comments|post comment

SSL? [Jan. 17th, 2001|09:12 pm]
LiveJournal Development

lj_dev

[dormando]
[music |PvD1_06_Tell_Me_Why(The_Riddle)]

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.
link4 comments|post comment

Code... almost. [Jan. 17th, 2001|11:44 pm]
LiveJournal Development

lj_dev

[bradfitz]
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.
link4 comments|post comment

(no subject) [Jan. 17th, 2001|11:57 pm]
LiveJournal Development

lj_dev

[revjim]
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.
link8 comments|post comment

navigation
[ viewing | January 17th, 2001 ]
[ go | Previous Day|Next Day ]