Alex Little

Yesterday a few of us (Elia, Jenny, Michelle and I) gave some workshops/presentations at the Sussex Learning Network conference. All seemed to go very well, between the four of us we ran three sessions in parallel – and had lots of interesting questions and discussion. A FlashMeeting of the presentation Elia & I gave is available if you’d like to see how it went

Have been pretty busy last couple of weeks (hence no postings) and had few days off work here and there too! Much of my time has just been getting MSG ready and installed on our acceptance test servers, ready for the launch of MSG Presence Maps on LabSpace and LearningSpace on 17th May. All seems to be running fine now after a bit of fiddling around.

Have now started to think what we do to get more information into MSG from users’ OpenLearn profiles and what would be the most relevant infomation to show to try and get people chatting to each other. One of the problems I think we’re having with people not using MSG that much is because it’s essentially just a list of names, there’s no way of knowing about that person & whether they’re ‘worth’(!) chatting to or not. So … my thoughts on the aspects we could include…

1. biography info – getting the info/biography info users can enter in Moodle
2. courses in common – using the fact that you are enrolled on the same, say, 5 courses as user X means you’re more likely to want to chat with them than someone who only has one course enrolment in common with you?
3. forum/learning journal postings – finding the number and ratings of other users forums postings to discover their reputation, eg if their forums posting are rated highly you are more likely to want to chat to them?
4. photos – just grab users photo (if they’ve submitted one) from Moodle to show within MSG.

Much of this is guesswork and supposition, until we give it a go we’re not really likely to know what’s going to work. These are based on what may be currently available form the OpenLearn system (rather than things we’d need to first build into Moodle). Also, still not sure whether to just focus on a subset of these or all would be needed to create a useful system.

Any thoughts/comments/suggestions welcome as to whether including and or all of these would be good (or bad!) – or if I’ve missed anything I ought to include

Been thinking more about what to ‘do’ about embedding Google maps into the MSG block in LabSpace and what should be shown depending on whether the user is currently logged in to LabSpace. Now we’re thinking that the map should be displayed whether or not the user is logged in and it should display markers for all of the currently logged in users.

As these users might not be in your contacts list we’d only be able to display the location, no presence, name or any other information – so we’d need to use another colour marker (I think) to indicate their presence/personal details are unavailable to you.

The only difference (in the block map) between logged in and not logged in users, would be the fact that logged in users would have a link out to their ‘real’ presence map. This does seem to be quite restrictive for logged in users (as we do actually have the other data that’s displayed on the actual presence map) but I’m wary about making the LabSpace page too JavaScript heavy – which would be required to make the map embedded in the block monitor all the users/presence changes.

Any other suggestions/possibilities welcome as to how the embedded maps should function for logged in vs logged out users

Last night we had the official launch of the OpenLearn and LabSpace websites, they are both freely available for anyone to access at : http://www.open.ac.uk/openlearn and http://www.open.ac.uk/labspace respectively.

The evening went really well, people seemed really interested in what we are doing, and there already been plenty of users registering for the sites. Obviously my main interest is how people get on with the tools in the in LabSpace site, especially MSG, so if you have any feedback or comments about this then please let me know – either leave comment below or email me directly

Spent last couple of days getting ready for the OpenLearn launch tomorrow. We’ve created a short demo video to show all 3 of the KMi tools (MSG, Compendium and FlashMeeting) being used together, we’ll get the video put up on the web hopefully sometime next week.

Still been getting some quite erratic problems with launching MSG from the web browser (or using the click to chat function) – and it’s quite hard to replicate any of the problems as they aren’t occuring reliably, a possible reason is that some of the ‘messages’ are getting lost either between browser & Moodle server or between Moodle server and MSG server.

Final thing we’ve (well, actually Chris!!) been working on is to resolve the problem that enrollment on a course in Moodle doesn’t filter through to the MSG application for a few hours. This looks very odd for users, especially first time users, as teh MSG block in Moodle will show a number of contacts, but launch MSG and none of them appear. The reason is due to the 6 hour cache on the Wildfire (MSG) server. We could reduce this, but then performance of MSG client may suffer. Chris has worked out a ‘cunning plan’ where by when a user logs in to MSG this triggers a background process to update the cache for that particular user. This should mean that the MSG groups/membership details will appear straight away rather than having to wait for the cache to expire.

Found that for now we can just carry on using the ‘old’ Moodle 1.6 functions for roles and permissions and we’ll update to the new 1.7 functionality later in October.
Chris and I are getting very close to having the Jabber server properly connected up to Moodle – still a few more things to do, like checking that the Jabber server can log a user in based on being passed the Moodle cookies. Had a bit of a nightmare yesterday when I tried to connect my Moodle up to Chris’s desktop PC, and I updated the blocks setting, unfortunately the firewall (or something) was blocking the connection between my dev Moodle and Chris’s PC – the resulted in my Moodle site just hanging. I couldn’t go back and edit the setting (because the site was hanging). Eventually got this fixed by commenting out the code which tries to connect, which then allowed me to edit the block setting. I had hoped to just be able edit the settings in the Moodle database, but I couldn’t find where the global settings are stored for a block – though I could find where they are stored for a block instance.

I then tried to implement the stream_set_timeout() function (to stop this happening in the future) – so that fsockopen didn’t just hang the server, but I couldn’t get it to work correctly. I could really do with getting this working so that we can return a decent error message if the Jabber server isn’t available for some reason (but Moodle is still running).

I’m also going to implement some security on the group and user services provided so that the results will only be returned if they have originated from one of the given IP addresses.

Now have my demo server updated to use the current version of the OU VLE Moodle with the LabSpace theme applied. Still getting very confused about the new roles and permissions, I’ve set up the db/access.php page as it looks like it ought to be set up – then I update the version number and run the admin page, but my new capabilities aren’t imported into the database – I can’t quite work out what’s going wrong here. few other queries I have about the new roles are permissions are:

• docs say that the capability should start with the path to the block or mod, but then the example given is block/… which of course ought to be blocks/… if it’s the path

• The get_context_instance() is passed an id as the second parameter, and I’ve seen a few examples which all use the instance id but I can’t work out how this should be applied to my block – which would usually be a sticky block so each block won’t have an instance id to use? The examples all seem to be something like:

• For user enrolments on courses – how can I figure out if a user is enrolled on a course without using mdl_user_students? I can see the mdl_role_assignments so I assume it’s something to do with this, but I’d need to know what the ‘student’ role was actually called to be able to query reliably – wouldn’t want to have the role id or role name from mdl_role hard coded into my php?

Anyway, for now I’m just going to leave my code using the old Moodle 1.6 functions/tables as I know these will still work with Moodle 1.7 (just deprecated) until I find someone who can help me sort it out!

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:

5. 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!

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!!

9. Encryption/decryption of the user’s jabber id
10. Verifying the Moodle session cookie – at the moment relying on user typing in password, but that’s just for my testing purposes
11. Enabling the ‘Launch MSG window button’
12. 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.
13. 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!

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.

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.