Archive for August 2006

Thursday 31 August 06

After having a chat to Chris & Marc now they’re both back from holiday, we decided to take a little step back and so now we’ll just develop the Moodle block so that it reflects the users current status, rather than allowing them to also set their status. This means that we avoid the thorny problem of maintaining the jsessionid for the users and knowing when they ahve gone on/offline etc.

I’ve also been working on getting some stats displayed within the block to show how many users are on and offline. We’ll have something along these lines:

My Contacts: (A) / (B) online

All users: (C) / (D) online

Where the figures are calculated as follows

(A) = number of current users contacts currently online – this has to currently be worked out in a slightly obscure and inefficient way… it thakes the ids of all the users currently online and feeds these as a where clause to the same query used to calculate (B) – this then gives total no of users contacts online. This works ok for low numbers of contacts and people online, but will start to get slow once the nubmer increase. A better way to do this would be to have this figure provided directly as a service from BuddyXML server – same goes for all the other figures too.

(B) = total number of users contacts – taken from Moodle database of the number of people who share a course with the current user.

(C) = total users currently online – calculated from the presences feed for the global user – again would be better if this was a feed/service direct from the BuddyXML server

(D) = total no users in system – taken from number of users on Moodle database

Friday 25 August 06

Found a way to replace the alt text – it involves creating a new element, assigning the required attributes and finally then overwriting the original img tag, here is some sample code:

var oldImg = myNode.firstChild;
var newImg = document.createElement(‘img’);
newImg.src = "/new/path/to/image/jpg";
newImg.alt = "my new alt text";
           
myNode.replaceChild(newImg,oldImg);

Note that this is very basic example and probably only works when ‘myNode’ has a single child node which is of type ‘img’.

Friday 25 August 06

Getting on better now! I’ve got the presence icon in the forums displaying as a live feed – and updates dynamically when I change my presence state in the MSG client, all I’ve got to sort out now is ensure that the link is active/inactive when the user switches between online and offline states. One thing I’ve noticed is that although I can get the image to update dynamically, I can read the alt text, but I’m unable to edit it dynamically (in FireFox anyway)  – I need this done for accessibility, if the alt text starts off as ‘free for chat’ (with corresponding image), then the user switches to away, I need the alt text to switch to ‘away’ too. It’d be a shame if the alt text was read only and can’t be altered dynamically, as it may mean I have to replace the whole <img> tag, rather than just the src and alt attributes.

I’ve also got the number of users online display to update dynamically. With both of these dynamic changes I’ve put config option in the block settings so the time between checking for changes can be altered.

Friday 25 August 06

With the problems etc I outlined yesterday I’ve been thinking that we might be trying to make it all overcomplicated by allowing the user to change their presence from within the block – and all the associated problems this entails with maintaining session ids in Moodle and JavaScript, knowing when they’ve expired etc. I think our best bet would be maybe concentrate on getting ‘live’ presences showing in the forums, and just have the Moodle block as a link out to launch the MSG window – maybe just have the block showing number of online users. So today I think I look into how I can make the no users online appear as a live count and how the users presence can be made ‘live’ in the forum display.

Thursday 24 August 06

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!

    Friday 18 August 06

    All has been goinng well so far with the integration of MSG into Moodle, I’ve got the forum listings update so they show whether the forum poster is currently online or not. Yesterday I started working on the block which will show the current users presence state and allow them to alter it, or log out/in from MSG. This is where things have started to get a lot more complicated! The main reason for this complication is that fact that I’ve got to use a proxy for the AJAX in my block to connect to which will then forward the requests on the the MSG server. This would be ok if it wasn’t for the fact that I need some way of maintaining the sessions, if the user is solely logging in to MSG through our Moodle block then that’s fine – I can hang on to the JSessionID required by the MSG server, but users could have logged in to MSG via another method, eg, though another browser window, or via the MSG Desktop Alert and this is quite likely, esp if they are using the desktop alerter.

    If the user has already looged in I don’t want to be creating another session for them (as it could confuse things), but as Moodle will be on a different domain, I don’t have access to the JSessionID cookie – so I’m unable to maintian the same session for the user.

    There are a couple of options of how to get around this (I think) – firstly would be to pass the Moodle session cookie to the MSG server and then the MSG server can maintain conenctions based on the Moodle session too – I don’t know how complicated it would be to set this up on the MSG server yet. For info, we’ve got a validate script that the MSG server can use to call Moodle to check that the given Moodle session cookie is valid and belongs to the user it claims to be from. The second option would be to have another service on the MSG server which could be sent the Moodle cookie (MSG checks it’s a valid one) and then provides back the users JSessionID.

    Until Chris is back next week and he can let me know which of the 2 options is viable (or not, or give me another option!) I’m going to concentrate on requiring the user to log in using Moodle and maintaining the JSessionID within Moodle.

    Tuesday 15 August 06

    Yesterday I started ‘properly’ on the Open Content (now known as OpenLearn!) project. Was quite strange to leave IET on Friday, especially as there weren’t many people around (everyone seemes to be off on holiday/study leave at the moment), but got all five years worth of stuff packed into a single box – quite impressed with myself about how much I could just throw away!

    The OpenLearn and MSG stuff is going well so far, I’d already made a reasonable start on it all over the last few weeks with the odd days I had working on MSG. Both of the main people I’ll be working with (Marc & Chris) are away at the moment, but I’ve certainly got plenty to be getting on with for the next few weeks, first deadline is end Sept, sure we’ll have something up and running by then, but probably with limited functionality.

    Thursday 10 August 06

    I’ve just got my new laptop so am getting all the bits and bobs installed on here that I’ll need for the OCI work. I’m going through the process of installing Apache, MySQL, PHP etc (I’d prefer to do this myself than to use one of the all-in-one installers, just so I know how it all really works!). nearly there with it now, just a couple of things I noticed on various forums etc about getting PHP5 to work with Apache 2.2, a fair few forum postings mention downloading php5apache2_2.dll to use instead of php5apache2.dll. I found that I didn’t need to do this, and instead of adding a LoadModule command to the Apache httpd.conf file, I just added this at the end instead:

    ScriptAlias /php/ “c:/PHP/”

    AddType application/x-httpd-php .php .php5

    Action application/x-httpd-php “/php/php-cgi.exe”

    SetEnv PHPRC “C:/php”

    I then also needed to update the directory security section in the httpd.conf file too, to allow Apache access to the PHP directory.

    For info, this was the best tutorial I found for getting all this set up – although it’s for MySQL 4.1, it still holds for MySQL 5.

    Monday 7 August 06

    Had the final project meeting for the JoinIn project last week, up in Manchester, so we demo’d all the software runing from my tablet PC. All seemed to go well, we’d had a bit of a frantic time getting it running properly, as I was using different versions of PHP and Moodle to the versions Juliette had been using on her machine for the development work.  Anyway, all worked out well in the end – just got to help finish writing the final report for the project now.

    Last week in IET this week before I move over to KMi, so have got lots of packing to do! Looking forward to getting started full time in KMi though 🙂