Have now pretty much finished off moving the MSG block to use JSON style services instead on XmlHttRequest and Chris has made quite a few updates to the BuddyXML service and MSG Client so we don;t get the odd little problems I previously mentioned. One big change is the ability to hook onto existing sessions, so for example if you log in with the MSG web client and then log in with MSG alert, they’ll use the same session, whereas previously you would actually be running two separate instances.
We’ve still got a fair bit more testing to do I think, but so far all seems good 🙂
Now I’m back on the Visual C++ stuff for updating MSG Alert, which is moving (very slowly!) forward, I’ve still got plenty to learn there I think 🙂
Spent the last few days updating the MSG-Moodle block so that is uses the JSON method rather than XmlHttpRequest and all seems to be going quite well. It will certainly make the application much more responsive as it makes the MSG-Moodle block a ‘proper’ client rather than having all the communication going via Moodle using a global user. It also means we can flag up when a user receives messages and they are always logged in to MSG if they have logged in to Moodle.
We still have a few problems to overcome, for example the fact that you could have multiple ‘clients’ running – eg the standard MSG Client and MSG-Moodle which causes a few problems for one grabbing presence and message notifications before the other has also obtained the data – this is because the data sits in a queue which is cleared when it;s returned to the client, so if it’s obtained for one client then the queue is clear when the other client requests the info. Hopefully we can get a neat solution to that one.
in the end I think we’ll have ended up almost re-writing the MSG block, but I think it;s definitely worth it if we can get it running ok – especially as it’ll remove all the ‘mess’ of caching presences etc within the Moodle database.
Also having ‘fun’ trying to implement the new roles and permissions stuff in Moodle, really can’t seem to get it to work how I want, and very few examples of how to use the roles and permissions with blocks seem to exist, the only one is in the RSS block – and I have a suspicion that this isn’t working correctly anyway (not 100% sure)
We’re now looking at how we could use JSON rather than XmlHttpRequest for the MSG-Moodle connection to the MSG server. The reason being that the users browser could then communicate directly with the MSG server (and not have to be proxied through Moodle) – and ought to make things a lot simpler and mean that I don’t need to cache all the presences on Moodle (and all the hassle that entails!) as they’d be gained directly from MSG server instead.
Made a bit of a start on it all, but have come up with a few little issues which can occur as you could effectively have 2 MSG clients running (one would be the ‘real’ client and the other running in Moodle).
Yesterday we updated the MSG client code, well, specifically the Wildfire customisations that provide the services for the MSG client. These changes should make quite a difference – especially with some of the problems some people were getting with login timeouts etc. More details of the updates.
Had no email access for last couple of days and there have been problems with the exchange server. My full mailbox hasn’t been restored yet, but in the meantime I’ve got a new mailbox I can use – just means that I haven’t got access to the last 3 months worth of emails – some of which has info in it I need 🙁 – nor can I get my calendar, contacts or to-do list. Hopefully this will all be restored from backup in the next day or so.
However, with no email access at all yesterday, meant that I was much more productive, and made a good start with the putting Google maps into Labspace in my dev environment.