Archive for September 2007

Voice and multi-user chat (via FlashMeeting integration)

I’ve now started work on being able to launch an instant FlashMeeting when you are using MSG. This would enable users to start up video & voice capabilities directly from MSG, rather than having to visit the FlashMeeting site seperately and book a meeting. It would also be a workaround for (all) those who want voice chat and multi-user chat as you could just instantly fire up FlashMeeting to get these capabilities. Most of the structure is now in place, we just need to get a service built which would book the FlashMeeting (behind the scenes) and check the FM server has capacity etc. Hopefully we should be able to get this implemented soon ๐Ÿ˜‰

Sound notifications

After not realising that I’d received an MSG message the other day because the window that received the message was buried under a heap of other windows, though I’d look at adding message beep when a new message arrives (MSGAlert already does this – but not the web client or MSG API). However it appears that using javascript (which is what I’d need to use) to trigger sounds in the browser seems to be fraught with browser (and audio player plugin) differences. I did find SoundManager2 which worked really well as it essentially uses an invisible Flash object to play the sound.

But then I tried (and failed) to get this implemented into the MSG Netvibes widget, and I *think* this is to do with the way Netvibes restricts calling external (to the widget XML) javascript code, whch is kind of a shame as that’s exactly where I wanted to put a beep notification. I’ll probably have another go at this next week to see if I can get this working – though I’m not too confident! I should also figure out how GTalk handles beeping when you get a new message.

MSG Netvibes widget update

I’ve just updated the MSG Netvibes widget to include a link to the MSG Presence maps page so you can launch the map without having to go through the MSG client first.

finally fixed character problem

I’ve finally got round to fixing the issue I had with the character encoding on my photo pages. Whereever “Mรผnchen” was printed, what actually appeared on the page was a question mark on black diamond rather than the u umlaut.

After bit of messing around I fixed the problem – turned out to be to do with the connection between PHP and MySQL, all I needed to do was add the command:
mysql_query(“SET NAMES utf8”);
before I did the query to extract from the database.

Previously I was looking as issues with the character encoding in the header, meta tags etc and couldn’t find anything wrong with these. Though not entirely sure exactly what this SET NAMES command actually does – will need to go & ook it up ….

Javascript addEventListener – peculiarity or bug?

Yesterday I was writing some javascript code to dynamically produce a list and add an event listener for when an item in the list was clicked on. When I then tested it out, for some reason the last event listener seems to have overridden all the others in the list. I’m not sure if the is a Javascript ‘feature’ or bug, but it occurs in both Firefox (v2) and IE (v6).
This is the code I tested:


function init(){
	var myUl = document.getElementById("test");

	for(var i=0; i<10; i++){
		var myLi = document.createElement("li");
		mySpan = document.createElement("span");
		mySpan.setAttribute("id","myspan"+i);
		myLi.appendChild(mySpan);
		myUl.appendChild(myLi);

		mySpan.appendChild(document.createTextNode(i));
		if(mySpan.addEventListener){ // Mozilla, Netscape, Firefox
			mySpan.addEventListener('click', function(){test(i);}, false);
		} else { // IE
			mySpan.attachEvent('onclick', function(){test(i);});
		}
	}
}

function test(myNum){
	alert(myNum);
}

This produces an unordered list of 10 items – (0-9), but when you click on any of the numbers the alert returns ’10’, rather than the expected 0-9 depending on which on you click. I could understand if it returned ‘9’ for every item in the list – but why 10?? I spent ages fiddling with this, but never did find what was actually causing this to occur – it seems like a bug to me – unless I’m just misunderstanding how the addEventListeners work? Maybe something to do with the fact I’m using anonymous functions?

If anyone has an explanation (or can point me to an explanation) as to what I’ve done wrong it would be much appreciated.

For info I managed to get around the problem by using the code below instead, though I’d still like to know what was wrong with my original code!


function init(){
	var myUl = document.getElementById("test");

	for(var i=0; i<10; i++){
		var myLi = document.createElement("li");
		mySpan = document.createElement("span");
		mySpan.setAttribute("id",i);
		myLi.appendChild(mySpan);
		myUl.appendChild(myLi);

		mySpan.appendChild(document.createTextNode(i));
		if(mySpan.addEventListener){ // Mozilla, Netscape, Firefox
			mySpan.addEventListener('click', eventHandler, false);
		} else { // IE
			mySpan.attachEvent('onclick', eventHandler);
		}
	}
}

function eventHandler(e){
	var e=e? e : window.event;
	var el=e.target? e.target : e.srcElement;
	alert(el.id);
}

No more ‘lost’ MSG messages

I’ve now implemented the chat history function on the msg.open.ac.uk server, so we can try it out there for little while, before I transfer it over to the msg-openlearn server.

I have found a couple of little ‘quirks’ which I’m not sure will annoy users or not…

  1. the chat history is only written to the log files every 120 seconds (or whatever no of secs I set it to), presumably to stop too many file read/writes which would have performance implications. But it means that if you have a conversation, close the window, then immediately re-open a chat with the same user and try to load the history, you may not see the message history from the last couple of minutes (the history will be there later, just not now). I don’t know that I can completely resolve this, but I have set the log files to be written every 30 seconds, so hopefully it won’t be an issue.
  2. another thing that may look a bit odd is that if you have a chat with someone for a little while, and then decide to load the history, the messages from over 2 mins ago will appear twice. I donโ€™t want to just overwrite the whole chat window, because then you wonโ€™t get the most recent messages (due to (1)), and I guess seeing the message twice is better than not at all. I think I’ve got a way around this, and that is to load mark the “loaded chat history” in the interface, so you know what is currently stored – and it then won’t look so odd that some messages appear twice.

Any feedback on the new chat history function is much appreciated ๐Ÿ™‚

Multilingual online users map block

well, English and Portuguese, so maybe bilingual rather than multilingual!

Thanks to Pedro Crispim for giving me the Portuguese lanugauge file for the online users map block ๐Ÿ™‚

It’s in the Moodle CVS if you’d like to download it and if anyone else feels like translating into other languages, please do – if you already have then send me the lang file so I can add it to the package for others to use ๐Ÿ™‚

MSG Chat History

Spent the day yesterday figuring out how I could implement a load chat history function in MSG – as one of the things I find a little annoying with MSG is that if you accidentally close the chat window, you can’t get the chat back – and if I find it irritating then I’m sure others do too ๐Ÿ˜‰

There were 2 ways I thought I could approach this…

  1. In BuddyXML (essentially the MSG server layer) intercept the messages as they are sent to/from users and store in files on the server, just in a directory structure reflecting the users involved
  2. Enable logging in the OpenFire server and parse these to give the user their chat conversation with the user selected

Each of these options has it’s pros and cons. Approach 1 means creating a new logging system (re-inventing functionality already implemented in OpenFire), but it would be quick to return the results to users (no parsing involved), whereas approach 2 has the opposite pros & cons – the logging is already implemented, but if the logs get big, it could take a while to parse/process them.

I decided to take approach 2, as it just *seems right*, but if it does start to become slow (with the parsing involved) we’ve got another method we could implement. In order to reduce the amount of parsing of log files, I’m restricting the conversation history returned to the last 7 days – although I’ll set the server to store the last 30 days, so we can increase the amount of history returned if it all works ok.

I’ve got most of this fixed up now and implemented – the final bit to put in place is to actually display the history back to the user in the chat window.

Hopefully this function with be useful to people (well, at the very least, I’ll find it handy!)