I ran into a old friend in Best Buy last week and he told me to look at this article – it took me a while to find it – so here it is – it was in Time Magazine February 26, 2007 – Page 51.
Here is a quote:
Clever entrepreneurs and even established companies can profit from this volunteerism–but only if they don’t get too greedy. The key, Benkler says, is “managing the marriage of money and nonmoney without making nonmoney feel like a sucker.”
Here is a URL:
http://www.time.com/time/magazine/article/0,9171,1590440-2,00.html
Working Towards Pluto 1.1.1 intrunk
Mostly geek-notes
JSR-168 Progress
Fixed my last Blocker level issue and improved my JSR-168 test portlet.
Add support for a real preferences store for JSR-168 portlets. The store is in
the Tool Placement, properties are prefixed with javax.portlet: and are URLEncoded.
Sometimes JSR-168 preferences are arrays – these are represented in Sakai
preferences as strings concatenated together with “!” – since the individual
bits are URLEncoded – there will be no “!” characters in the strings.
charles-severances-computer:~/dev/sakai/portal csev$ svn commit
Sending portal-render-impl/impl/src/java/org/sakaiproject/portal/render/portlet/services/SakaiOptionalPortletContainerServices.java
Transmitting file data .
Committed revision 22128.
charles-severances-computer:~/
The rest of this is just my current notes on 168 progress.
Compiling JSR-168
Instructions are really simple now:
svn co https://source.sakaiproject.org/svn//sakai/trunk/ sakai
cd sakai
svn co https://source.sakaiproject.org/svn//portlet/trunk/ portlet
maven bld dpl
Start tomcat. The portlets will simply show up as tools – you may want this in your sakai.properties:
webservices.allowlogin=true
webservice.portalsecret=plug-xyzzy
webservice.portalIP=127.0.0.1
webservice.IPCheck=true
JSR-168 Branch Merge – Fix Reset etc.
I made some progress here is the status for JSR-168. Pretty much all the big stuff is done (Broken reset was the last “blocker”). Here is status:
TODO:
Why to we register too many times?
Why do we doView more than once?
reference/docs/architecture – Update
JSR-168 Preferences – permanently persist in Tool Placement
Re-enable userInfo capabilities once Pluto 1.1.1 is released of we put it into the Sakai repo.
Nice to have
JSR-168 Edit Mode
JSR-168 Help Mode
DONE
PDA – Rename – Done 22111
Test Portlet – Done
Test CSS – Done
Reset – Fixed
PDA Presence – Fixed
My cool SVN statement – merged a branch all by myself!
svn merge -r 21991:HEAD https://source.sakaiproject.org/svn//portal/branches/experimental_portal_branch/
The rest of this is just notes form my desktop.
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.
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…
Talking about Kowari/Mulgara
I had this exchange – figured I would put it in the blog.
JSR-168 – More compiling instructions – getting Pluto jars
The one thing that was missing from my notes before is getting the Pluto 1.1 jars – here are two files that need changing.
I am not sure when I will check in the files – so I attach the diffs. Previously we would compile our own versions of these jars but as we approahc Pluto 1.1.0 release we can pull from the staging server.