Monthly Archives: February 2007

Powered by Pluto

Sakai is now Powered by Pluto. Here is proof.
http://portals.apache.org/pluto/powered.html
Sakai 2.4 will have support for JSR-168 portlets – trivial drop-in of a Pluto 1.1 style war file – even hot-deploy in Sakai.

NUSOAP – Chuck’s Experience

In my quest to produce an IMS Tool Interoperability Endpoint which requires a SOAP Server in PHP that handles the complex WSDL for IMS Tool Interoperability – I encountered NUSOAP. I must point out that I have never used nusoap until the last seven days – so I am *not an* expert.
But my general opinion is that nusoap is an awsome product – but poorly documented and not able to handle complex WSDL very well. It is like they did a superb job (I like the coding style of nusoap – the debugging feature is AWESOME) and built until it supported the WSDL that the nusoap folks had to work with and then stopped.
So most of my experience is getting nusoap to handle things that it did not handle out of the box.
I am happy to provide patches to the nusoap folks – but I am guessing that my inexperience with nusoap means that my patches would be architecturally “inelegant” and not good with the philosophy of nusoap – who knows. I may post a message to the nusoap dev list and watch the beatings begin.
The source is here (warning – this has lots of extra debugging code that I added to figure out the internals of nusoap operation – which I left in):
http://www-personal.umich.edu/~csev/sakai/imsti/
You can see the stuff online at:
http://www.sakaiproject.org/imsti-test
At the end of the day, it is no wonder that PHP folks really prefer REST. I was told that perl is better at handling SOAP – I would be curious. Paricularly because I would *love* to have a sample IMS TI tool in perl – but since I HATE the perl language this is not likely to be something that I would do.
Maybe my next foray will be trying to see if Ruby is better than PHP on SOAP parsing of complex and abstract types.

Continue reading

My Recent Obsession – Interoperability

I don’t know what has gotten into me but for the past few months I have been *obsessed with Interoperability – I just cannot get it off my mind. Perhaps it is because I keep drawing PowerPoints about how everything must be connected to everything. Perhaps it is my personal hidden shame that we did not do a better job connecting Sakai and uPortal during the Sakai Project (2004-2005). I don’t know why but lately I cannot stop thinking about Tool Interoperability.
Some points…

Continue reading

JSR-168 support

Thanks to a lot of work by Ian Boston and David DeWolf we have support for JSR-168 in Sakai.
I just finished fiddling around with it and wrote some documentation. Here are my notes about it…
I still need to work more on this documentation and play more with developing portlets- but the basic support seems solid and there.

Continue reading

A Really Good Day – IMS Tool Interoperabiltiy v2.0

I am at the IMS meeting at the Oracle Conference Center here in San Francicso. I have decided to focus my IMS energy on IMS Tool Interoperability Version 2 for the next year or so.
I have visited a lot of Sakai partners in the past year and one thing comes up all the time as an important use case. You don’t want to choose a single LMS system – you want to be able to mix and match from whatever system and what ever components you need.
This is like a holy grail – like a quest – and some have tried and come up short – SUNY is a good example where they insisted that hte “future is now” and ultimately ran out of steam and “lived in the present” and went with Angel (a good choice by the way).
Take a look at this response I wrote to SUNY over a year ago about the perils of this approach and why we need TI v 2.0 SO BADLY:
http://www-personal.umich.edu/~csev/papers/2006/2006_01_07_suny_rfq_response.pdf
So Tool Interoperability is a quest! It is a challenge – it is a mountain to be climbed – it is a standard to be developed. It is the search for the holy grail of LMS technology.
So, yesterday was a good day – sitting with the assembled knights (brave lady and gentleman knights BTW) from Blackboard, D2L, Angel, Wimba, Microsoft, and others it simply felt great to get my hands a little dirty.
The TI group has been meeting with great leadership from Chris Moffat of Microsoft for some time – but this is the first time I have joined the quest. The group is finishing the charter and I *hope* can get off the dime.
I wil be frank (please don’t tell anyone I said this) – I think that the key for TI2 is to come up with some web services for things like File Manager, Schedule Manager Mail System, etc etc and lets *Standardize* these things. This way, we can start writing tools that actually have rich functionality that run outside the LMS. I think that we just need to look at the web services in Angel, D2L, or Blackbaord – and pick something, clean it up, build up consensus and than standardize on it.
Hey – this is what hapenned for TI 1.0 (inspired by PowerLinks) and IMS Common Cartridge (inspired by Blackboard’s import format). Lets cut to the chase and do it for TI2.0 – lets find some successfull commercial approach and make it the standard so we can all implement the same thing and get interoperating.
Sorry for the outburst – I am just so excited – at the beginning it is all potential and no one has to put in the hard work :)
I also apologize in advance if I come to visit your site and I keep finding ways to bring up IMS TI in conversation – because I think that if TI2.0 is successful, it could be this is the most transformative technical achievement in the teaching and learning field.
Sheesh – I cannot stop talking about it.