«
»

Thursday 24 August 06

August 24, 2006, 12:28 pm by Alex | Comment

Here’s a brief(ish) update and overview of how I’m getting on with the MSG-Moodle integration. Firstly, what I have got working….

  1. Got the presences showing on the forum postings (though this is not a ‘live’ display – only the point at which the page was generated)
  2. Connecting up to the ‘global’ user and storing their session id (and ensuring that it’s expired and regenerated at the correct time)
  3. MSG block – shows number of users online (though again not ‘live’ display)
  4. MSG block shows status and allows users to login/out and change status – what I’ve done for this so far is really only temporary, quite a few changes will need to be made before I would say it’s really working!

There are a few problems with what I’ve done so far:

  1. If the user is already logged in to MSG (eg via desktop or other browser window), I can pick up the fact that they are logged in, but I can’t ‘attach’ to their session as I can’t find out their jsessionid – so the only way the block currently works properly is if the user logs in to MSG via the block. A couple of potential solutions to this would be:
  1. Have another service on the BuddyXML server which provides the jsessionid for a given user – not sure how secure this would be, probably not very – as potentially people could get other users session ids…
  2. Just pass the Moodle session id with the request (the BuddyXML server can verify this using the validate page I’ve written in my block). This means the block wouldn’t need to try and keep track of the jsessionid at all. Not totally sure this would work well as probably will raise other problems – but can’t think exactly what just now!
  • If the user logs in by clicking on a presence icon (eg the “free for chat” icon) they get logged in ok, but although it’s displayed as being “free for chat” if the page is refreshed they are actually logged in as “online” – it appears that the login is processed, then the command to set their actual status (the one the user clicked on) is processed, and finally the BuddyXML server sets their status as online. I noticed that if I put an alert in to notify the user that the status has changed, then it all works as expected – so I’m guessing that it’s to do with concurrent requests to change status being sent to the BuddyXML server and one being process before the other. Might be able to fix this by putting slight pause in-between sending the login command and notifying of the ‘real’ presences state.
  • I’ve tried to implement the waitForEvent() method, which seems to work (after a fashion), but it _really_ seems to slow down navigating from page to page within Moodle, or even just refreshing the page. I can’t explain why this doesn’t seem to happen with the MSG client (though could be that we’re not navigating through these pages and the problem may become apparent if we did).
  • Currently the jsessionid is stored in javascript and in Moodle, I can’t just store it in the javascript as when someone navigates to another page it would be lost – so needs to be stored in Moodle too – to supply the javascript with when a new page is visited. This presents the problem of knowing when the jsessionid on the Moodle side has expired. If the user goes to another page which doesn’t contain the MSG block (eg, an activity page) then there won’t be any requests going back to the BuddyXML server with the jsessionid, so the chat session would expire, even though the user probably doesn’t want this to happen (I would assume they’d still want to be logged in to MSG when they return to the course page containing the MSG block) – or maybe not??
    Anyway, a way around this, providing we’re happy for people’s sessions to go offline if they visit another page for 5 mins and they’ve not got either the MSG desktop or another chat browser window open, would be to maintain a timestamp in Moodle of when jsessionid was last passed to the BuddyXML server. If it’s over 5mins (current default timeout on BuddyXML server?) then jsessionid is wiped.

    • Some of the solutions feel a bit ‘hacky’ to me, so maybe I’ll think of better ways to do some of these!

    Still to do, apart from getting the above problems resolved!!

    1. Encryption/decryption of the user’s jabber id
    2. Verifying the Moodle session cookie – at the moment relying on user typing in password, but that’s just for my testing purposes
    3. Enabling the ‘Launch MSG window button’
    4. Enabling the click to chat function – so when user see’s someone is online in the forums in one click they can open a chat window to that user.
    5. Switch to using a simple service for getting a particular users presence – at the moment I get a list of all the current logged in users, and need to iterate though to find the particular user I’m looking for – this is ok for a short list but it there are many users this could get very time consuming (and a lot of redundant data being passed). So a simple service which just provided the presence for an individual user would be much better

    There are still things to do after this (obviously!), for example checking that it’s all working using the new version of Moodle – with updated roles & permissions functionality, ensuring that the jabber id is correctly generated when the user registers, checking they have the opt in/out function etc etc etc!

    Tags: , ,
    Category: Tools, Web dev & programming  |  Comment (RSS)  |  Trackback

    Leave a Reply

    CAPTCHA Image
    *