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.
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.
Working with complex SOAP is a pain in PHP - I used nusoap because it seemed to be a good place to start. My verison of nusoap is modified in two ways. I am not exactly sure if these modifications are right so folks should feel free to disagree with my mods or tell me that I am confused w.r.t SOAP.
Support for Multi-Part Messages
It does not appear that nusoap client handles SOAP of the following form:
<SOAP-ENV:Body>
<ProxyToolLaunchResponse>
<LaunchDirective>
<PerformRedirectAction>
http://127.0.0.1:80/~csev/nusoap/samples/LMSTool.php?session=6
</PerformRedirectAction>
</LaunchDirective>
</ProxyToolLaunchResponse>
<imsx_syncResponseHeaderInfo>
<imsx_version>1.0</imsx_version>
</imsx_syncResponseHeaderInfo>
</SOAP-ENV:Body>
The nusoap client parses it all and gets it all right and then only returns the first part. I added code to lib/nusoap.php at line 5953 to detect if there were multiple root documents after parsing and return an array of all of the root parts rather than just the first one.
Look for the string "theMessage".
Support for Abstract Types
The IMS Tool Interoperability uses derived types and abstract classes. The nusoap outbound serialization seems to have NO support for this. Here is some sample WSDL:
<xs:complexType name="OutcomeProfile.Type" abstract="true">
<xs:annotation>
<xs:documentation>
</xs:documentation>
</xs:annotation>
<xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MinimalOutcomeProfile.Type">
<xs:annotation>
<xs:documentation>
</xs:documentation>
<xs:annotation>
<xs:complexContent>
<xs:extension base="tns:OutcomeProfile.Type">
<xs:sequence>
<xs:element ref="tns:LaunchProfile" minOccurs = "1" maxOccurs = "1"/>
<xs:element ref="tns:Grade" minOccurs = "1" maxOccurs = "1"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="OutcomeMessageRequest">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:OutcomeProfile"/>
</xs:sequence>
</xs:complexType>
</xs:element>
The nusoap serializer wanted to serialize OutcomeMessageRequest so it went looking for OutcomeProfile - if you put this in your array labelled "OutcomeProfile" it would see the definition of the abstract class (OutcomeProfile.Type) and conclude there was nothing to serialize. If you labeled things as "MinimalOutcomeProfile.Type" then nusoap would not see any relationship between OutcomeMessage and MinimalOutcomeProfile.Type and again refuse to serialize.
The solution is a new feature I added to nusoap. The ideas is that you make an entry for "OutcomeProfile" and then within that, you point to the actual implementation of the type. Here is the syntax
I used:
'SecurityProfile' => array (
"SOAP:Implementation" => "SharedSecretSecurityProfile.Type",
'SharedSecretSecurityProfile.Type' => array (
"MAC" => "00:ff:ff:ff:00:00"
)
)
You add a "SOAP:Implementation" tag within the entry for the abstract type and tell it the real implementation type - it is basically like a redirect - "Hey you are typing to serialize a SecurityProfile - but really the schema for this is actually a SharedSecretSecurityProfile.Type". It works pretty well - I am not sure if I am generating good WSDL or not - I will have to validate this with Axis (have I ever told you how much I despise it when WSDL hackers go crazy and do elegant stuff?).
It serializes like this:
<SecurityProfile>
<MAC">00:ff:ff:ff:00:00</MAC>
</SecurityProfile>
I don't think this is quite right because there is no real indication of the implementing type for the consuming folks. But I was happy just to get this to work at all. If someone who is a SOAP/WSDL expert can tell me how to fix this let me know. nusoap is a big hog/monster but I think I have a handle on it. The code is around line 5569 of lib/nusoap.php. Look for the string "Redirecting".
What about PHP5?
This is all PHP4 because it comes shipped on my Mac :). So I use nusoap. In PHP5 some of this is built in and so either it is magically fixed or - it is broken and not easily fixed.
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...
IMS Tool Interoperability Version 2 is starting and I am getting pulled into it. Wimba and Microsoft are leading and doing a great job. I secretly (don't tell anyone) just want to adopt the PowerLinks web services as IMS TI version 2. I like PowerLinks web services - I only have seen a high level document - but what I see looks nice. Of course IMS TI 1 is based on and pays homage to a small subset of PowerLinks back inthe WebCT days.
Sakai will support RSS, Atom, and OPML feeds for version 2.4. This allows you to track a bunch of Sakai servers with federating RSS feeds - you can get a system-wide (all sites) or a single site feed. This is the end of a task that I set for myself at a bar in New York City drinking a pint of Guiness with Bill Thompson of JA-Sig and Rutgers fame. I was exasperated at hte time, having tried everything to connect Sakai and uPortal in a way that *made the users happy* - we had put a lot of effort into demonstrations which were a lot of work - but users just yawned. SO I said to Bill - "What *do* you portal guys want??" - he said, "Make me some iCal feeds and RSS feeds - I wil send the RSS through some XSLT and make a nice dashboard for my users - they can just launch into your app from the dashboard if they like.". He added, "and believe me - I do *not* want Sakai to run *in* my portal - I just want a good usefu; dashboard.". I like that kind of thinking.
Sakai 2.4 will also support JSR-168 using Pluto 1.1. At the same time uPortal 3 should also use Puto 1.1 instead of Pluto 1.0. This means that the *exact same war file* can be dropped into uPortal or Sakai and the portlets will jsut work. SO we have war portability - something that the portal community does not do well at all. But with Pluto 1.1 (the magic sauce) we converge on a portable WAR format by choosing the same implementation. Not to mention the speed at which Sakai and uP3 can get to JSR-286 by soimply following Pluto. These efforts have nicely brought the Sakai, uP3, and Pluto communities much closer together. So this is like a nice little treansportable tool unit - finally JSR-168 is having some effect.
I played with the IMSTI tool in Sakai and worked with Anthony and helped make it work on HSQL db. Then to test it I needed a test jig so I wrote this:
http://www.sakaiproject.org/imsti-test/
This includes source code to provide basic support for launch PHP tools using IM TI. This also will help a lot in testing TI features.
I learned a lot about nusoap and really and truly reached the conclusion that SOAP is crap. No wonder everyone does REST - after 6 days struggleing with SOAP - REST seems like nirvana.
Enough for now.. Back to catching up on EMail riding the Michigan Flyer bus from Detroit to Lansing with it cool and free wireless.
I had this exchange - figured I would put it in the blog.
--- The note from Noah
I'm really interested in the Kowari stuff, but I'm just not sure about
expecting service/tool developers to push all their interesting data
atoms. I like the caching/speed options that offers, but that can't be
the only way to get data. I guess there's no reason at all that one of
these data queries couldn't use whatever data was available in Kowari
and pull the other pieces needed. I just never want to tell someone
"you can't get there from here".
When I get some more of it built up, I'm sure there will be potent
examples (and pretty docs!) for the busiest among us to test drive
quickly and move on with life. Like you said, talented people are
crawling into the discussion, so this must not be too far off target.
I'll keep you lightly posted on what's happening.
------ My Response
Cool - I am looking to validate or reject a basic hypoethesis about Kowari.
Ian and others who I really respect tell me that Kowari is *different*. it scales unlike any prior object database or RDF store. It does this by *absolutely* not using any relational technology - it effectively used RAM and spinning disk with random I/O to do very fast has like stuff over large data sets. Also it spreads the data out over servers making best use of RAM and disk and CPU across the servers.
In a way, it is like Lucene - it takes a different approach and accomplishes something that RDB systems cannot no matter how much you tune them.
If on the other hand, Kowari is just another really rich API on top of a RDB - then I will be disappointed and relegate it to "something that sounded good but had no game in the final analysis. :)
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.
charles-severances-computer:~/dev/sakai/master csev$ svn diff
Index: pom.xml<
===================================================================
--- pom.xml (revision 21139)
+++ pom.xml (working copy)
@@ -71,6 +71,15 @@
<enabled>false</enabled>
</snapshots>
</repository>
+ <repository>
+ <id>Pluto Repor</id>
+ <name>Pluto Dev Repository</name>
+ <layout>default</layout>
+ <url>http://people.apache.org/builds/portals-pluto/m2-staging-repository</url>
+ <snapshots>
+ <enabled>false</enabled>
+ </snapshots>
+ </repository>
</repositories>
<dependencies>
~/dev/sakai/charon_velocity_portal/portal-shared-deploy csev$ svn diffIndex: pom.xml
===================================================================
--- pom.xml (revision 21139)
+++ pom.xml (working copy)
@@ -18,7 +18,7 @@
<dependency>
<groupId>org.apache.pluto</groupId>
<artifactId>pluto-container</artifactId>
- <version>1.1.0-SNAPSHOT</version>
+ <version>1.1.0</version>
</dependency>
<dependency>
<groupId>javax.portlet</groupId>
@@ -28,17 +28,17 @@
<dependency>
<groupId>org.apache.pluto</groupId>
<artifactId>pluto-descriptor-api</artifactId>
- <version>1.1.0-SNAPSHOT</version>
+ <version>1.1.0</version>
</dependency>
<dependency>
<groupId>org.apache.pluto</groupId>
<artifactId>pluto-descriptor-impl</artifactId>
- <version>1.1.0-SNAPSHOT</version>
+ <version>1.1.0</version>
</dependency>
<dependency>
<groupId>org.apache.pluto</groupId>
<artifactId>pluto-taglib</artifactId>
- <version>1.1.0-SNAPSHOT</version>
+ <version>1.1.0</version>
</dependency>
<dependency>
<groupId>castor</groupId>
This is my install log for a fresh check out of Sakai getting 168 to work.
Set up Maven 2 per this:
http://bugs.sakaiproject.org/confluence/display/ENC/Using+Maven+2Set up Maven 2 per this:
http://bugs.sakaiproject.org/confluence/display/ENC/Using+Maven+2
~/dev csev$ svn co https://source.sakaiproject.org/svn/sakai/trunk/ sakai
~/dev/sakai csev$ svn co https://source.sakaiproject.org/svn/portal/branches/charon_velocity_portal/
Checked out revision 21139.
dhcp-op350-conf-center-west-95-172:~/dev/sakai csev$ svn co https://source.sakaiproject.org/svn/portlet/trunk/ portlet
dhcp-op350-conf-center-west-95-172:~/dev/sakai csev$ vi pom.xml
<module>osid</module>
- <module>osp</module>
+ <!-- <module>osp</module> -->
<module>podcasts</module>
- <module>portal</module>
+ <!-- <module>portal</module> -->
+ <module>charon_velocity_portal</module>
<module>postem</module>
<module>presence</module>
~/dev/sakai csev$ mvn -o -Dmaven.test.skip=true -Dmaven.tomcat.home=/Users/csev/dev/apache-tomcat-5.5.20/ clean install sakai:deploy
~/dev/sakai/portlet csev$ maven sakai
~/dev/apache-tomcat-5.5.20/common/endorsed csev$ cp ~/dev/save-apache/common/endorsed/xercesImpl.jar .
~/dev/apache-tomcat-5.5.20/common/endorsed csev$ ls -l
xercesImpl.jar -rw-r--r-- 1 csev csev 1207073 Feb 8 09:13 xercesImpl.jar
---- START TOMCAT ----
Create a new account in Sakai
Create new worksite in Sakai
In the tool registration you should see things like SakaiLaunch
Simply select one of the portlets
Go to the site and click on the portlet
Do not worry about this log entry - it is from the portlet and it is just whining loudly that
it cannot find a remote web service.
Remote User=csevdoView site.list = null sakai.host=null
autoLogin = null autoDone=null remote=csev session=null
loadSiteList host=http://localhost:8080 id=csev pw=plug-xyzzy auto=true
session=null host=null user=null placement=null
First Name=null
Last Name=null
EMail=null
Portal Login http://localhost:8080/sakai-axis/SakaiPortalLogin.jws id=csev pw=plug-xyzzy
SakiaPortalLogin.login()
SakaiPortalLogin.loginAndCreate id=csev pw=plug-xyzzy sec=
SakaiPortalLogin.loginAndCreate ip=127.0.0.1 portalIP= IPCheck=
fn=null ln=null em=null ip=127.0.0.1Exception:Failed login
If you forget to put xerces in common you will see this in the log.
Feb 8, 2007 9:08:43 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive sakai-portlets.war
java.lang.RuntimeException: Could not instantiate parser org.apache.xerces.parsers.SAXParser: java.lang.ClassCastException: org.apache.xerces.parsers.XML11Configuration
at org.exolab.castor.util.LocalConfiguration.getParser(LocalConfiguration.java:332)
at org.exolab.castor.util.LocalConfiguration.getParser(LocalConfiguration.java:263)
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:678)
at org.exolab.castor.mapping.Mapping.loadMappingInternal(Mapping.java:535)
at org.exolab.castor.mapping.Mapping.loadMapping(Mapping.java:438)
at org.apache.pluto.descriptors.services.castor.PortletAppDescriptorServiceImpl.getCastorMapping(PortletAppDescriptorServiceImpl.java:102)
at org.apache.pluto.descriptors.services.castor.AbstractCastorDescriptorService.readInternal(AbstractCastorDescriptorService.java:45)
~/dev csev$ svn co https://source.sakaiproject.org/svn/sakai/trunk/ sakai
~/dev/sakai csev$ svn co https://source.sakaiproject.org/svn/portal/branches/charon_velocity_portal/
Checked out revision 21139.
dhcp-op350-conf-center-west-95-172:~/dev/sakai csev$ svn co https://source.sakaiproject.org/svn/portlet/trunk/ portlet
dhcp-op350-conf-center-west-95-172:~/dev/sakai csev$ vi pom.xml
<module>osid</module>
- <module>osp</module>
+ <!-- <module>osp</module> -->
<module>podcasts</module>
- <module>portal</module>
+ <!-- <module>portal</module> -->
+ <module>charon_velocity_portal</module>
<module>postem</module>
<module>presence</module>
~/dev/sakai csev$ mvn -o -Dmaven.test.skip=true -Dmaven.tomcat.home=/Users/csev/dev/apache-tomcat-5.5.20/ clean install sakai:deploy
~/dev/sakai/portlet csev$ maven sakai
I added this to is my sakai.properties which I took from ~/dev/sakai/reference/demo/sakai.properties
gatewaySiteList=!gateway,mercury,snork
webservices.allowlogin=true
webservice.portalsecret=plug-xyzzy
webservice.portalIP=127.0.0.1
webservice.IPCheck=true
---- START TOMCAT ----
Create a new account in Sakai
Create new worksite in Sakai
In the tool registration you should see things like SakaiLaunch
Simply select one of the portlets
Go to the site and click on the portlet
Do not worry about this log entry - it is from the portlet and it is just whining loudly that
it cannot find a remote web service.
Remote User=csevdoView site.list = null sakai.host=null
autoLogin = null autoDone=null remote=csev session=null
loadSiteList host=http://localhost:8080 id=csev pw=plug-xyzzy auto=true
session=null host=null user=null placement=null
First Name=null
Last Name=null
EMail=null
Portal Login http://localhost:8080/sakai-axis/SakaiPortalLogin.jws id=csev pw=plug-xyzzy
SakiaPortalLogin.login()
SakaiPortalLogin.loginAndCreate id=csev pw=plug-xyzzy sec=
SakaiPortalLogin.loginAndCreate ip=127.0.0.1 portalIP= IPCheck=
fn=null ln=null em=null ip=127.0.0.1Exception:Failed login
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.
I recently finished some improvement of the auto registration process for Sakai support of JSR-168 portlets.
I also wrote some documentation which is in
/reference/docs/architecture/sakai-168-portlets.doc
And attached.
The primary feature is to add more control to the portlet registration process
including the ability to add a tool registration file for a portlet without modifying the
portlet war file as well as a property to control the auto-regitration behavior.
Requires modifications to tool/ActiveTool up to revision 21132.
See requirements SAK-8022 and SAK-8349.
This puts JSR-168 support in Sakai 2.4 in a really solid state.
My next steps are actually to adapt refactor my existing portlets a bit write some simple sample portlets to complete my documentation on how to write a portlet in Sakai.
If you want to use this code, you need to take the follwoing steps:
- Get maven 2 working
- Check out the trunk of Sakai
- Check out the charon_velocity branch
- Make the following changes to the root pom.xml - comment out osp and replace portal with charon_velocity portal
-
+
-
+
- Compile it all - perhaps check to see if it starts
- Add a war file with Pluto 1.1 portlets in it to your webapps directory (I have one attached)
- Start Tomcat - look at the logs as per the documentation - make a site, add some portlets
- If you are adventurous check this out
https://source.sakaiproject.org/svn/portlet/trunk/
and put in a director called portlet - you compile this with "maven bld dpl" as it is not yet M2.
Lather, rinse, and repeat.
My work was small and simple clean up - Ian and David did the very heavy lifting on this effort.
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.
Again taken from my desktop...
svn co -r 20000 https://source.sakaiproject.org/svn//sections/trunk/ sections
Here are the *.read functions
annc.read
asn.read
calendar.read
chat.read
content.read
disc.read
a bunch of dissertaion reads - let Dick figure those out
messagecenter.read
rwiki.read
What about this: ./message/message-tool/tool/src/webapp/tools/sakai.motd.xml
announcement/announcement-tool/tool/src/webapp/tools/sakai.announcements.xml
announcement/announcement-tool/tool/src/webapp/tools/sakai.synoptic.announcement.xml
vi mailarchive/mailarchive-tool/tool/src/webapp/tools/sakai.mailbox.xml
vi chat/chat-tool/tool/src/webapp/tools/sakai.chat.xml
./message/message-tool/tool/src/webapp/tools/sakai.synoptic.chat.xml
/message/message-tool/tool/src/webapp/tools/sakai.synoptic.discussion.xml
vi calendar/calendar-tool/tool/src/webapp/tools/sakai.schedule.xml
vi calendar/calendar-summary-tool/tool/src/webapp/tools/sakai.summary.calendar.xml
vi discussion/discussion-tool/tool/src/webapp/tools/sakai.discussion.xml
vi content/content-tool/tool/src/webapp/tools/sakai.resources.xml
vi rwiki/rwiki-tool/tool/src/webapp/tools/sakai.rwiki.xml
./msgcntr/messageforums-app/src/webapp/tools/sakai.messagecenter.xml
./msgcntr/messageforums-app/src/webapp/tools/sakai.synoptic.messagecenter.xml
WHAT ABOUT NEWS???
# sakai.properties - the demo edition
gatewaySiteListDisplayCount=99
gatewaySiteList=!gateway,snork,zorch
iframe was already done
announcement calendar chat content discussion/ mailarchive/ message/ rwiki/ site-manage/ web
announcement/announcement-tool/tool/src/webapp/tools/sakai.announcements.xml announcement/announcement-tool/tool/src/webapp/tools/sakai.synoptic.announcement.xml calendar/calendar-summary-tool/tool/src/webapp/tools/sakai.summary.calendar.xml calendar/calendar-tool/tool/src/webapp/tools/sakai.schedule.xml
chat/chat-tool/tool/src/webapp/tools/sakai.chat.xml content/content-tool/tool/src/webapp/tools/sakai.resources.xml
discussion/discussion-tool/tool/src/webapp/tools/sakai.discussion.xml
mailarchive/mailarchive-tool/tool/src/webapp/tools/sakai.mailbox.xml
message/message-tool/tool/src/webapp/tools/sakai.synoptic.discussion.xml
message/message-tool/tool/src/webapp/tools/sakai.synoptic.chat.xml
rwiki/rwiki-tool/tool/src/webapp/tools/sakai.rwiki.xml
site-manage/site-manage-tool/tool/src/webapp/tools/sakai.siteinfo.xml
web/news-tool/tool/src/webapp/tools/sakai.news.xml
This is just some random notes from my desktop.
TODO - Portlet Portal
http://bugs.sakaiproject.org/jira/browse/SAK-8180
Suppress/enable login/logout with parameter and session variable
Look into resizing the frame above us. - Probably not practical...
Generally switch macros.vm to use simpler context approach stuff and normalize what we put into context - low priority
What about presence coming back on each click as part of the context - will need to do this for RSS.
-------
Skin Better - Done
- Overlaps on tiny screens
Presense - Floating div - Done
http://www.developer.be/forums/index.cfm/fuseaction/dsp_full_thread/fullthreadid/1408/forumID/10.htm
http://www.devx.com/tips/Tip/12867
Test Popup - Done
Refactor code so Ian's stuff uses my new routines - Done
Solve log in and log out for dense portal - Done
Option 1 - always log in
Option 2 - allow anonymous...
Fix bottom nav in page and in portlet. - Done
Don't show presence in the MyWorkspace - Done
1) Check out trunk
2) check out
svn co https://source.sakaiproject.org/svn/portal/branches/charon_velocity_portal/
vi pom.xml
- <module>portal</module>
+ <module>charon_velocity_portal</module>
vi osp/pom.xml
- <module>portal</module>
+ <!-- <module>portal</module> -->
<module>presentation</module>
mvn -Dmaven.test.skip=true -Dmaven.tomcat.home=/Users/csev/dev/apache-tomcat-5.5.20/ clean install sakai:deploy
I used this quote in a recent note where someone (one more time) suggested that a vote be the way we allocate volunteer resources in Sakai (setting me aflame as usual).
I apologize in advance to its somewhat offiensive nature :)
Some in America (myself included) look at "votes" as the mindless polling of poorly educated individuals who have been programmed by watching endless commercials interspersed in between soft-core porn reality shows - so that we can have the perception that there is democracy afoot *somewhere*".
Sorry - that *was* pretty cynical - it is not entirely true - but kind of funny.
Blackboard has made a legal non-revokable non-assert patent pledge which formalizes their position on patents with respect to open source course management systems like Moodle, ATutor, Sakai, and many others. For many months Bb has said "they had no intention to sue universities" and the community has asked Bb to put that in writing - this pledge is "in writing". :)
The patent pledge is available at:
http://www.blackboard.com/patent
Sakai and Educause have prepared a statement which should hit the web sites of Sakai and Educause soon. I attach the final version below.
The Boards of Directors of the Sakai Foundation and of EDUCAUSE recognize the patent pledge announced on February 1, 2007 by Blackboard as a step in a more positive direction for the community, to the extent that it offers some comfort to a portion of the academic community that uses open source or homegrown systems. In the pledge, Blackboard states that it will not assert certain patents against open source or home grown systems bundled with no proprietary software. We particularly welcome the inclusion of pending patents, the clarification on the commercial support, customization, hosting or maintenance of open source systems and the worldwide nature of Blackboards pledge. We also appreciate the willingness of Blackboard to continue with frank and direct dialogue with our two organizations and with other higher education representatives and groups to work toward addressing these problems of community concern.
Although Blackboard has included in the pledge many named open source initiatives, regardless of whether they incorporate proprietary elements in their applications, Blackboard has also reserved rights to assert its patents against other providers of such systems that are "bundled" with proprietary code. We remain concerned that this bundling language introduces legal and technical complexity and uncertainty which will be inhibitive in this arena of development.
As a result, the Sakai Foundation and EDUCAUSE find it difficult to give the wholehearted endorsement we had hoped might be possible. Some of Sakai's commercial partners and valued members of the open source community will not be protected under this pledge. Furthermore, EDUCAUSE and Sakai worked to gain a pledge that Blackboard would never take legal action for infringement against a college or university using another competing product. While Blackboard ultimately agrees that such actions are not in its best interest from a customer relations viewpoint, it could not agree for reasons related to its existing legal case. Our organizations will remain vigilant on this point as protecting our member institutions is of top priority.
While this pledge offers a formalization of Blackboard's past claims about the intent of its patents, it does not speak to the quality or validity of the patents themselves. Sakai and EDUCAUSE maintain the position that Blackboards U.S. patent number 6,988,138 is overly broad, and that the U.S. Patent and Trademark Office (USPTO) erred in granting it to Blackboard. Furthermore, we believe that this conclusion will ultimately be decided by the re-examination of this patent through the USPTO and in the current litigation.
We hope that all of the organizations and individuals interested in educational technology will continue to focus our collective energies on improving software, and system and data interoperability with the ultimate goal of delivering truly innovative solutions to all teachers and learners.