Evan Martin (evan) wrote in ijournal,
Evan Martin
evan
ijournal

I was forwarded a support request about some iJournal-related problems and it seems you guys are doing some wacky stuff that's causing you problems.


I can't look at the code directly (sourceforge is broken again... does this surprise anyone?) but it seems at least a few of these apply to iJournal:
  • You assume moodids are contiguous.
  • You aren't caching moods.
  • Your protocol response parser is broken in some way.


First, nobody else has reported this problem with moodid 50, and the word from Brad is:
Reviewed the code, seems fine.

...

And there is no 50:

mysql> select * from moods where moodid between 48 and 55;
+--------+---------------+------------+
| moodid | mood          | parentmood |
+--------+---------------+------------+
|     48 | indescribable |          0 |
|     49 | sleepy        |         31 |
|     51 | groggy        |         31 |
|     52 | hyper         |         11 |
|     53 | relaxed       |         15 |
|     54 | restless      |         74 |
|     55 | disappointed  |         25 |
+--------+---------------+------------+
7 rows in set (0.00 sec)   


So they're probably assuming things are contiguous.

Here's a clip from the docs for the login mode:
If your client supports moods, send this [getmoods] key with a value of the highest mood ID you have cached/stored on the user's computer. For example, if you logged in last time with and got mood IDs 1, 2, 4, and 5, then send "5" as the value of "getmoods". The server will return every new mood that has an internal MoodID greater than 5. If you've never downloaded moods before, send "0". If you don't care about getting any moods at all (if your client doesn't support them), then don't send this key at all.

It's not stated explicitly, but that example shows the possibility of missing mood id 3. But really, even if you assumed all the moodids did exist, a well-designed client should notice that moods[50] is null and not break in other ways.

Now, this problem should not really be coming up for most people because you definitely are supposed to cache the mood list client-side. That's why getmoods takes an argument. So once you have the mood list once, the users should never be experiencing any parse errors while parsing a mood list, because they shouldn't be getting a mood list on subsequent logins.

Finally, I'm not sure what your parser is doing, but the absence of a moodid 50 should not corrupt other keys (unless LJ really is outputting invalid responses, but I don't think it is). I won't venture to guess what you're doing, but it really shouldn't be that complicated (otherwise we might as well all be using XML-RPC). Here's a clip from logjam, where res is the server response, util_getline returns an allocated copy of the current line, and util_skipline returns a pointer to the next line:
    while (*res != 0) {
        key = util_getline(res);
        res = util_skipline(res);
        if (*res) {
            val = util_getline(res);
            res = util_skipline(res); 
            /* insert key/val pair into hash table. */
            g_hash_table_insert(hash, key, val);
            read_keys++;
        }
    }


Finally, here's a dump from when I login with the "test" account (after clearing my local mood cache):
mood_48_name
indescribable
mood_49_id
49
mood_49_name
sleepy
mood_4_id
4
mood_4_name
anxious
mood_50_id
51
mood_50_name
groggy
mood_51_id
52
mood_51_name
hyper

This tells me that moodid 49 is sleepy, 4 is anxious, 51 is groggy, and 52 is hyper.

Please let me know if you need any more information!
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 7 comments