Even if it did work now, I wouldn't be surprised if it stopped working in the future-- those are two separate modes and probably should remain separate.

(Anyway, syncitems times are based on the *modified* times of entries; if I run syncitems to get my full journal, then I edit an entry in 2000 now, then run syncitems again, I get that one entry in the response.)

I don't quite understand why you want to use the two together. What is the advantage? You can use usejournal with syncitems, too.

According to the documentation on syncitems, it doesn't support the usejournal tag. Are the docs out of date? Does it support it?

I'm being a stickler for the amount that is downloaded. The syncitems mode has a lot of comment items in it which I don't care about. The getdaycounts doesn't have these. This is perfect for a calendar widget, however, I don't want to have to get the full calendar every time. I want to do this once, store it locally, and each subsequent calendar widget showing, I want to be able to sync that via getentries.

I guess I'll just have to call syncitems everytime. I was just trying to avoid the useless comment entries in that listing.

I suppose the documentation is out of date, and it's also likely it's unintended behavior. I only discovered it by just trying the request and having it succeed. (We've discussed syncing usejournals a few times but had no conclusion... it'd be nice to be able to back up your communities, but some people might claim there are privacy issues.)

And avoiding bandwidth is a good reason. Hopefully, the comment items aren't that much: just a few letters. Might it be useful in the future to allow the client to specify a "filter"? (I was just looking at this code on the server and I think it'd be trivial to add.)

I like the idea of the filter. It's a bit confusing about what total_count and the normal count means. I suppose you just take the latest date off any entry (comment or otherwise) and use that for the next syncitems call? With me just concerned about the entries, the filter would help in the count/total_count weirdness. ;)

And no, it's not such a big deal having to filter out the comments (or even parse them for the next syncitems date). It's not that much text. With syncitems, it is going to be a one time thing for the user (the initial download), so it's not *that* much bandwith to worry about.

I was a bit surprised that getentries with usejournal returned other posts besides the user's, but I hadn't even thought of owning a community. For that, I suspect it makes sense.

I do feel a bit uncomfortable about using usejournal with syncitems if it is a loop hole though. ;)

I made http://ljkit.sourceforge.net

It may or may not be useful to you. It doesn't handle syncitems though, I haven't thought up a good API for that yet.

I did find your lib, and it's been very helpful a few times in understanding LJ's protocol. Thanks for that. The objective for this project is try my hand at the Mac OSX api, so I've been staying away from ready to go libs and rolling my own.

I know this makes you cringe. When you write a lib, you want everyone to use it. Sorry. :)

No cringing --- I wish you the best. I hope if you develop some good code you'll consider contributing to LJKit. :-)