I believe the client should send a login request once, and not before every postevent. Sending it before every postevent is wasteful (if client stats are a problem, they should be fixed on the server in this case), and not sending it at all is a bigger problem - we want to be able to refuse old clients eventually as the protocol changes, and the natural place to do it is in the login mode.

We're not enforcing login mode before postevent mode now, but if it ever becomes a problem, we might (at the cost of have stateful logins, which is a bother).

AFAIK you don't need that, because every request seems to be authorized seperately. Therefor you also send username and password / hpassword with every Request.

The Python LJ Archiver, I wrote for me also does not need a login request at first to successfully send a synitmes request for example.

I see the other two people to answer have missed the point, more or less.

I see what you are getting at. For the purpose of client stats, it appears you are saying the logging is broken, since it will use the client stats for whomever has logged in most recently.

Obviously you will have to login once, to find out what journals the client can post to, so it is not an issue of login before each post vs. don't login.

I can't think of a good way to fix this, beyond returning a unique key (Or client ID) on login, and refusing the post if the key is given and does not match the last key given out. But that is kind of messy and breaks the current one request/one connection made that the protocol has. This would require 3 connections for one request. Alternatively, passing the client name/version to the post would also help with this.

If clients were smart and saved data between sessions, they would only have to login once every week if that. I know LochJournal has always logged in once per session. It saved the moods to a file so that the server didn't have to regurgitate all of that--even though there's already a database hit to get the rest of the information, so the point is moot.

As for the stats, as far as I'm aware it only records the number of users that actually use said client. As long as the client sends in a login event once, it should work fine. Are there other stats that I'm not aware of?

Well since I didn't know the full story, being a new client developer, I decided to check the LJ code. Sure enough, it only really uses it twice. Once for login, to register that the client was used, and once for userinfo.

Oh yeah, and stats of course. For stats, it does a count of clients who have logged in in the past 30 days.