Unfortunately, the API doesn't allow you to simply *update* the security with a simple command (at least not that I'm aware!). You do have to download the whole post and send it back to them with the changes.

When you *delete* a post, you simply send a blank editevent. Hence the speed difference, LJDel can get away with retrieving less information via syncitems.

In practice, I don't know if you'd see that much speed change. A program interacting with the flat interface probably spends more of its time sending challenge / response type authorizations. :)

Although my program LJ-Sec primarily is for changing security, it also can perform bulk deletes and bulk find/replace. There are some other programs out there that incorporate parts of this functionality -- for instance, Hidejournal can hide entries, and I think there's a couple other clients that can perform bulk find/replace or deletes.

Great :) I'll check out Lj-Sec!

> I don't know if you'd see that much speed change

Like in that screen shot, it did 700 entries in 30 minutes.

> A program interacting with the flat interface probably
> spends more of its time sending challenge / response type
> authorizations. :)

Hmm... actually, the challenge / response happens only the first time.

Thereafter, you can just use the generated session in a cookie.

I'll have to time a security change sometime, oddly enough that seems slower than I remember it took to change my journal! Then again that may be dial-up times vs. cable modem.

I would do the cookie thing if I could figure it out, I couldn't get it to work using the .NET web request methods (and I'm too busy to write something custom at this moment :) ). Probably something silly I'm missing (I suspected it's the X-LJ-Auth: cookie custom header that's tripping me up or something like that.) Challenge / Response ended up being pretty darn fast oddly enough.

Don't bother. I'll give you the code. I was planning to put it up anyway.

makeRequest is a method I wrote to... make a Request :) and return a NameValueCollection.
private NameValueCollection makeRequest(string PostData, bool UseLjSession)

makeRequest has an extra bool UseLjSession which is used thus

-code-
if (UseLjSession)
HttpWebRequest1.Headers.Add("X-LJ-Auth", "cookie");
-code-

calculateMD5Hash is another custom method. CookieContainer1 is my HttpWebRequest's CookieContainer.
I call all these first like this

-code-
NameValueCollection NameValueCollection1 = makeRequest("mode=getchallenge", false);
string AuthResponse = calculateMD5Hash(NameValueCollection1["challenge"] + calculateMD5Hash(Password));

NameValueCollection1 = makeRequest(string.Format("mode=sessiongenerate&user={0}&auth_method=challenge&auth_challenge={1}&auth_response={2}&expiration=long&clientversion=xxx", UserName, NameValueCollection1["challenge"], AuthResponse), false);
CookieContainer1.Add(new Cookie("ljsession", NameValueCollection1["ljsession"],"/", ".livejournal.com"));
-code-

There after you make all your requests with the cookie :)

-code-
NameValueCollection1 = makeRequest(string.Format("mode=getevents&user={0}&auth_method=cookie&truncate=10&noprops=1&selecttype=lastn&howmany=50&ver=1&prefersubject=1", UserName), true);
-code-

Let me know if anything is unclear :) So I take it you were generating a challenge for every post since a challenge can only be used once... Yes, that would definitely be slower.

Cool. That gives me what I need to know to change the methodology to use the cookie. :)