?mode=live lives again!!!!!!! ;)

(Reply to this) (Thread)

?mode=live is currently live on the site, but I doubt it works. I removed it from cvs the other day, knowing this was on its way, and to make the code cleaner.

(Reply to this) (Parent) (Thread)

Neat.

(Reply to this) (Thread)

Sounds cool.

(Reply to this) (Thread)

This does deal with edited entries correctly, right?

(Reply to this) (Thread)

It's not even released yet. So relax.

(Reply to this) (Parent) (Thread)

So that's a "no" then. ;^>

(Reply to this) (Parent) (Thread)

I'm so going to start randomly bolding text in my posts now. It's on like donkey kong.

(Reply to this) (Parent) (Thread)

Wow.

I've been waiting for you to do this eventually, with your enthusiasm for
XmlHttpRequest... but, Wow.

(Reply to this) (Thread)

you're a clever cat.

(Reply to this) (Thread)

Rock on. Anything that reduces load makes me a happy admin :)

Why aren't we 304'ing If-Modified-Since requests on those immutable URLs already? It would save some requests from googlebot.

(Reply to this) (Thread)

for the current entry pages on lj, they can change -- you can edit the post, or get another comment, etc. i think brad constructs unique urls each time the page changes so a given url is always static.

(Reply to this) (Parent) (Thread)

There aren't many immutable URLs right now. Just /userpic/* really.

(Reply to this) (Parent) (Thread)

(Reply to this) (Thread)

It won't be user-customizable. Likely/maybe CSS for font/colors/etc, but not S2, and not S1. There might not even be user CSS, just a selection of a few themes users can select. I want to control the DOM and classnames and ids so I can do things like commentmanage.js easily, without each and every fucking style having to advertise its DOM structure, and none working perfectly.

(Reply to this) (Parent) (Thread)

(Reply to this) (Parent) (Thread)

this sounds familiar...

(Reply to this) (Parent) (Thread)

Yeah, we give the hard projects to the interns. :-)

(Reply to this) (Parent) (Thread)

Speaking of S2 and CSS and customizability, this S2 thingy I made might interest you. I heard rumblings at some point from someone there at Danga who was going to make it a system style, but I think that that idea got mentally lost in the move down to SF.

(Reply to this) (Parent) (Thread)

So how's that ?start= for friends pages coming, hm? You know, the one that was in the works YEARS AGO? :P

(Reply to this) (Thread)

Not gonna happen. Doesn't scale. The friends page algorithm is finishes in 's' steps, where 's' is the number of items to view. The ?start= would require way more indexes (beyond being worth it) and/or an algorithm that runs in 'f' steps, where 'f' is your number of friend, which also won't happen.

However, bookmarkable URLs are totally doable, encoding in them the content of the page, and where you're at in time. Then the previous/back links can be optionally shown, if the time you're viewing the page is within the 2 week scrollback period.

As for solving the "I was away on vacation for 3 weeks" problem where you want to catch up going forward in time, that's more of the always-talked-about-but-never-done ESN system, which is actually now on our roadmap after Scrapbook improvements, but since I'm not so involved with Scrapbook, I might work on ESN a bit earlier.

In fact --- much of my work on this javascript friends page is to make ESN integration a lot easier in the future.

(Reply to this) (Parent) (Thread)

Okay, bookmarkable URLs is all I wanted to start with. :)

What is ESN?

(Reply to this) (Parent) (Thread)

(Reply to this) (Parent) (Thread)

Ok, I can't quite infer what the ?start= would be, but I guess bookmarkable URLs would address the "going forward in time, you'll miss entries if anyone updates" issue?

Topic #2, nothing to do with the above: isn't the fact that shift-reload is only going to reload the javascript loader code actually a bad thing, not a good thing, since it breaks the actual point of shift-reload (which, for me, at least, is "hey browser, some of this stuff didn't load right for some reason, uncache it and try again")? I'm not clear what the use case is for where you want shift-reload to do less (well, from a user's standpoint, it's obvious from an LJ-load standpoint).

(Reply to this) (Parent) (Thread)

presumably when you put this into place, it would auto detect that your browser could support, and do it the old way, if the browser didn't support Javascript fully?

(Reply to this) (Thread)

Yeah. Or more likely tell you to go use the friends page, since this system is at a different URL.

There will be a new option to let you disable your friends page... either completely, or just the link to it from your journal.

So for a couple years (or likely forever), the friends page will still exist for those that don't want to use the fancy version.

(Reply to this) (Parent) (Thread)

see.. once it was working, I would default it to the new system, and then allow a user to select much like they can select a page style for LJ, select which manner they wish to use.

(Reply to this) (Parent) (Thread)

Naah, it'll be so different, it'll be opt-in. I won't make it the default.

(Reply to this) (Parent) (Thread)

Or more likely tell you to go use the friends page, since this system is at a different URL.

Could those with no javascript get bounced to a (possibly re-written, since it apparently wasn't 'clean code') version of mode=live? That would allow javascript-less people to enjoy the live view.

(Reply to this) (Parent) (Thread)

Not going to happen.

(Reply to this) (Parent) (Thread)

Ah, well, thanks for the answer.

(Reply to this) (Parent) (Thread)

Wait. This means you have machine-readable interfaces for (a) retrieving entries and (b) retrieving entry links for the friends list. Are these going to be published interfaces?

(Reply to this) (Thread)

That was my first thought - this could all become client-based! Oh, to have a nice news-reader type interface for LJ.

(Reply to this) (Parent) (Thread)

Yup. They exist and they're even live, albeit at a "secret" URL. I doubt they'll become published or "stable" interfaces, though, since the product is sure to change rapidly over the next several months.

But I suppose another version can be made stable.

(Reply to this) (Parent) (Thread)

Oh, yes please. :)

(Reply to this) (Parent) (Thread)

Such a shame, all of those unused CPU cycles out there... I'm speaking of those who are repeatedly hitting their refresh button in the first place.

Sure wish I could show them ads while they were waiting. :-)

(Reply to this) (Thread)

Go away. :P

(Reply to this) (Parent) (Thread)

Can we see it yet?

I'm imagining mouseover comment# links having a popup list of usernames that have commented and other cool stuff...

(Reply to this) (Thread)

bossome.

(Reply to this) (Thread)

Is that when the boss does something awesome?

(Reply to this) (Parent) (Thread)

I hope you can get before/after stats of what you attribute to load contribution of serial reloaders.

It seems like it would go a long way to removing one of my bad user habits.

(Reply to this) (Thread)

Speaking of JavaScript, you might like this stuff I've been writing lately.

(Reply to this) (Thread)