||[Nov. 27th, 2001|09:56 am]
LiveJournal Client Discussions
Quick question to all client developers...|
Before sending a postevent, do you send a login first?
The reason I ask, is 1) Obviously there will be another request to the server (higher load), but 2) it ensures that the post gets allocated against the correct client id.
For example, you have two clients running (separate machines/platforms), and they're both logged in. If you post from one and then the other, and they don't send the login mode first, they'll both be allocated against the same client.
For me, who is watching client stats very closely, this is not good.
So, would it make sense to send login before postevent?
2001-11-27 12:10 am (UTC)
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.
2001-11-27 11:13 am (UTC)
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.