Dr. Chuck's Web Log

Open Letter - About the "Roadblock People"

This is a letter to anyone who feels that the "Central Sakai People" - Chuck, Glenn and Lance as examples - are roadblocks to progress - and those people who keep harping on this in public and private mail.

I wrote this a few weeks back and then left it in drafts - to let myself cool down and and re-read this before blogging.

Usually the mail goes something like this: You central people are such a bunch of roadblocks - could you do X for me?

You have this all backwards. The "Roadblock People" have no desire to review all of the patches and there are hundreds of patches that go in without any review at all.

The problem is that there is that no one else is competent to review patches to the deepest parts of the system. The community is *not* well served at all just opening the gates of patches to the deep parts of the code. Then we will end up with crap - and then someone will still have to dig through and figure out why production servers are crashing or losing data - guess who will dig in and fix things - the Roadblock People - guess who will be blamed while Sakai is broken - not you - the Roadblock People. Because no one else will stand up to the task of taking responsibility for code in good times and bad - we depend on the RoadBlock People.

So until someone gets to the point where they have the skill and commitment to insure long-term quality of the code we wisely use the precious people resources that we have. Sadly at that point they "join" the Roadblock people and start throwing up roadblocks - so that we ship clean code in their areas of responbsibility. The reward for becoming a RoadBlock person? You guessed it - getting accused of being a roadblock while working 12 hour days and over the weekend.

There are hundreds of little things in each release - not just the things you want. Look at the SVN logs. New tools always have rough edges - guess who cleans them up - hmmm. the Roadblock people. Surprisingly no one else from the community feels the need to go through every new element of code and check for little errors. So the roadblock people 12 hour days for the two weeks after code freeze so the release is not garbage.

Where is the rest of the community here? I will tell you - sending email messages about how broken things are and how their *particular* thing is not getting attention because the whole project is screwed up or complaining about how one or another procedure was bent - but not *doing* the work.

When you (the person making the roadblock accusation) are willing to give me 30 hours of each of your weeks to work on tasks that I assign to you - let me know. I am sure that you will say (and rightly so) that you are too busy. I accept that explanation. With that why is it so hard for you to accept the explanation that other people are busy too? You can claim busy - but no one else can? Is that your rule?

Always couching conversations with something negative - "the process is broken - I need X" - this is unprofessional and not respectful of the dedication and commitment of the other members of the community and their commitment to the common good - being attacked continuously wears on people - everyone shoud find more positive ways to express what they need.

You have enough credibility in this community that when you say you need something - we do listen.

I so greatly value your skills talent and contribution that it feels weird sending even a mildly negative message to you. But you just keep resorting to the negative in your approach. The negativism is damaging and it is *not* necessary. Shrouding everything in a cloud of negativism is more likely to slow things down over time rather than speed them up. It is OK to remind folks when things seem to slip through the cracks - just don't add the "zinger" about how broken everything is.

I have this zinger problem as well. I send a message that is 90% logical and on point - and then I add a "zinger" - something negative that causes my whole message to be ignored. When I do it - friends help me by pointing it out.

I hope that I re-read this message several times to eliminate any zingers :)

K12 Summit - Speech Notes and Blog Photos

I gave an off the cuff speech at the recent K12 summit (http://k12open.fi.ncsu.edu/). I could not use PowerPoint (gasp). So I wrote some notes.

Pictures start here.

My speech notes start here.

What is Sakai and the SF

- Open source Collaboration and Learning Environment
- 2.5 years old
- 200 sites approaching a million users
- Active in Standards like IMS
- Member supported non-profit $1M / year - 105 members
- Volunteer developers
- Apache like commercial friendly license
- RedHat like commercial affiliates

Issues in Successful open source governance
- Value and protect those who make commitment and those who do the work for the common good
- Arrange motivation arrows so they lead toward contribution
- Need diversity of community- developers, designers, users, teachers, etc. Geographic diversity - Higher Ed, Community College, K12, lifelong education

Multiple models of approaching Open Source
- HE direct - HE indirect through vendor
- CC indirect
- K12 likely will be indirect because of nature of the market

How to Contribute
- Developer, QA, design requirements, sharing experience, participating in communities of practice.
- HS can contribute - may be QA, bugs, requirements

Sakai to teach Software Engineering
- VA Tech already in doing this at grad level - moving toward undergrad
- Sakai is like a worldwide 100 person mid-cap tech company that operates in the open - like watching an ant farm

Keys for K12
- Need to create and promote success stories - must over invest up front and not give up.
- Must improve packaging of Open Source software
- Standards and interoperability a must

Misc points

Redhat did not invent O/S - they showed how to profit from O/S by adding value without ruining the O/S community.

Tom Rabon: Collaboration is the heart and soul of open source.
Passion + Curiosity trumps IQ
"I would rather be collaborating" - T-shirt

The "Y-axis of the stack" is "value" - it is different for different verticals. For developers it is power and convienence, for games, it is frames per second, for higher education IT - it is innovation, for K12 education is "out of the box integratability.

Notes on Bob Suter.

It is hard to define "open" - it is easier to define things that are "imperfections" in "open".

It usually comes down to when you will be told "no". Do you or your organization have to pay *anything* to play?

Can you see all the conversation?

How do decisions get made?

Final panel - K12 Low Hanging Fruit

My notes start here. This is the low hanging fruit note.

Open Source SIF Agent for Sakai

Find existing K12 Sakai deployments - find use cases which were solved and make sure to get them back into the main Sakai release.

A really simple cut down distribution of Sakai that installs for small production in 20 minutes on commodity hardware commonly available in K12.

Work with K12 publishers to see if Common Cartridge can be used to get content into the hands of teachers.

Notes from Sakai Integration Week 2.3

Sakai 2.3 Integration week went really well. With less than six weeks between Sakai 2.2 ship and Sakai 2.3 freeze a surprisingly large amount of work was done and 2.3 is looking like a nice release.

An number of requirements saw some important progress.

Here are the pictures:

http://www.dr-chuck.com/images/2006/09/index.php?img=11-09-06_181447_01.jpg

The attendees were: Andrew Poland, Megan May, Ian Boston, Josh Holzman, Lance Speelmon (Polycom), Jim Eng, Glenn Golden, Beth Kirschner, Zhen Quiang, and Guarav Bhatnagar (from the SakaiBrary project).

Carol Dippel (Sakai QA Director until last June) made an appearance - she happened to be in town visiting and we ran into her at dinner one night:

http://www.dr-chuck.com/images/2006/09/index.php?img=15-09-06_122817_01.jpg

Here are pictures of the board about what we worked on during the week:

http://www.dr-chuck.com/images/2006/09/index.php?img=15-09-06_171926_01.jpg

Beacon - Will be a Quartz job - not done yet - may not be done - if this does not get done, we can contrib this
Ian's Hierarchy work will stay contrib
The Charon Portal was flattened with the removal of two of the worst iFrames leaving only the presence and tool body frames. (a requirement)

http://www.dr-chuck.com/images/2006/09/index.php?img=15-09-06_171926_02.jpg

We took a set of patches from IBM that makes it easier to deploy Sakai in WebSphere
We added a capability to deep link URLs through Charon into tools - this is still under some debate so folks should use caution when trying to use this - it might change (this addresses some requirements)
We were going to try to refactor the FCK editor so that it came form textarea rather than reference - this was tabled as we wanted to free Joshua to the Common Cartridge group so that test questions would be auto-imported.
Zach Thomas and a small band of developers refactored import - adding common cartridge (a requirement)

http://www.dr-chuck.com/images/2006/09/index.php?img=15-09-06_171926_03.jpg

We are going to Java 1.5. Sakai 2.3.0 will ship so that it could run under Java 1.4 - but we are only going to QA Sakai 2.3 on Java 1.5 and are going to "not support" Sakai 2.3 on Java 1.4 - We will police the trunk keeping *out* Java 1.5 dependencies until 2.3 is released - the maintenance branch will *not* be policed and will be allowed to move to Java 1.5.
So the Short summary here is that you should expect to run Sakai 2.3 on Java - 1.5 - you have three months to get ready for this.
We went through and removed any remaining Hibernate 1 syntax so we could change the query parser to be the modern query parser. This was done by a great effort on the part of the folks who support Hibernate apps. Things in contrib may need some work for 2.3. Check with Josh, Aaron, or Lance for details.
Resource Ordering (from requirements) is in.
Resource release / retract (from requirements) is in.
Course management API is in - Josh has providers and Quartz Jobs that you can use if you prefer to integrate your SIS data using the CM approach. This is something that is best thought of as provisional (kind of like search in 2.2) - work with Josh and the CM team if you want to use this new CM integration point.

http://www.dr-chuck.com/images/2006/09/index.php?img=15-09-06_172054_01.jpg
http://www.dr-chuck.com/images/2006/09/index.php?img=15-09-06_172850_01.jpg

SAK-5295 was not fixed - hopefully it will be fixed during QA
SAK-4295 (Basic Auth) was put in
SAK-5197 and SAK-6033 MySql performance patches - did not make it in but need to get in soon. I do not like to leave performance patches hanging across versions.
SAK-4120 - Role based buttons is in

http://www.dr-chuck.com/images/2006/09/index.php?img=15-09-06_172352_01.jpg
http://www.dr-chuck.com/images/2006/09/index.php?img=15-09-06_172155_01.jpg

Here is the provisional outcome:

Podcasts - Goes to provisional
Rwiki - goes to full
Calendar - goes to full
Jforum - - stays contrib
Mailtool - goes to provisional
Blogger - goes to provisional
T&Q - stays provisional
Roster - stays provisional
User Membership - stays contrib - it uses SQL in the tool - we need to move this SQL into the API
Sitestats - stays contrib - just too many performance concerns - we need to think this through
Link Took - moves to provisional
OSP - Stays provisional

A key thing here is that any tool that was moved to provisional is really still "on probation" - if we find something icky in Blogger, mailtool, linkTool, or podcasts - and it is not fixed in a timely manner we will push them back to contrib. The teams responsible for these tools are also responsible for testing them and reporting to Megan as to the fact that they pass QA.

If you find a reason that any of the newly provisional tools have a problem let us know.

Other stuff

Andrew came up with some Quartz jobs that clean up Event and Session tables so that these do not grow OOTB - this can be turned off if you like but we have seen cases where production ends up with performance problems when the DBA's don't clean this all up - so we decided to automate it.

Sakai Status Update

Well it is the end of summer, and then end of Integration week for Sakai 2.3 - probably a good time for a status report.

Focus on User Delight

With the 2.2 and 2.3 releases, Sakai's framework is pretty stable. There is a lot of innovation in the area of tools going on around the world and we can have some time to take a breath and work on the "user delight" aspects of Sakai. I am working to increasingly put the focus of our thinking on the uses and users of Sakai.

The requirements effort has helped to communicate the "will of the community" to our volunteer development team - in 2.3 (8 weeks of development) there are a number of areas of the requirements that were addressed. As we move toward 2.4, we need to revisit the requirements and make sure that the will of the community is well represented in the requirements so that developers can address many of these requirements over the next four months as we prepare Sakai 2.4. Mark Norton has been retained to lead and facilitate the requirements process.

I truly enjoyed my visit to Lubeck University and the EU Sakai days. they produced video summaries of the meetings:

http://www.oncampus.de/index.php?id=819&L=1

From the discussions at the meetings, it is clear that Europe will bring many new ideas to how we all will use Sakai to teach and learn. The Bologna process:

http://ec.europa.eu/education/policies/educ/bologna/bologna_en.html

may have a significant impact on the need to evolve the technology used in teaching and learning across Europe to meet these new EU requirements.

In my hobby as film maker, I am increasingly looking for "end user" Sakai stories to mix in with my Sakai developer stories. My first video in this new series is from Roskilde University.

http://www.dr-chuck.com/media.php?id=65

It focuses on how Sakai is used in and out of the classroom in a database class at Roskilde University taught by Henrik Bulskov.

Technical Bits

Summer 2006 was a pretty busy time for the Sakai community. We started the summer with the Vancouver conference. Sakai 2.2 was released in mid-July. With the Sakai 2.2 release we are moving toward a longer QA period acknowledging the increasing complexity of our product as we grow. To compensate fore this longer QA we have to move our freeze dates earlier - so the code freeze for Sakai 2.3 was moved up to mid-September.

So in the eight week period from mid-July through Mid September we were all pretty busy :). We released 2.2, we released 2.2.1, we released 2.2.2, we developed for 2.3, and code froze 2.3 - and of course for those of us in the northern hemisphere - we took August to prepare for the upcoming September production.

The good news is that we got it all done. The bad news is that folks are rightly tired after sprinting the whole summer. We need to pick it back up and do a good job on QA for 2.3.

The Sakai 2.3 release (even with about 6 weeks of development) is shaping up nicely. There are a lot of provisional tools integrated into the release and some nice cleanup in the portal, mail area, and the resources tool has some new features that came in through the requirements process.

Going Forward

For the people who have been involved in Sakai from early 2004, it feels for the first time that we can actually sit back and take a breath. It seems as though we have been sprinting for 2.5 years and now can finally sit down. This is a good time to move our focus from purely technical issues and look more broadly at what Sakai "should be" through our requirements process.

As of 2.3, we have adjusted the schedule so that we can be more relaxed. We roughly have four months of development, two months of QA, and release dates that allow 6 weeks of preparation for a January rollout and four months of preparation for a September rollout of a new release. This schedule shift resulted in a really short window for 2.3 - but it will help us greatly going forward.

Protal Improvement

We have a bunch of requirements about "saving state across navigation"
Legacy tools should not save state

http://bugs.sakaiproject.org/jira/browse/REQ-285

Sakai remembers state - optional?

http://bugs.sakaiproject.org/jira/browse/SAK-737
Sakai Saving State - Moving between tools and within pages of a tool should behave conistently for users.

http://bugs.sakaiproject.org/jira/browse/REQ-37

Basically the use case is simple - every time you move between tools or between sites, the tool that you "come back to" needs to be at its initial screen.

In Sakai 2.2 - when you "come back" you are brought back to where you left and the tool is in the state you left it.

As an example:

Go to resources - press the Add button - Go to Home - Go Back to Resources - what do you see?

In the state saving approach - you are at the Add screen - in the state clearing approach you are at the top of the resources hierarchy as if you pressed Resources for the first time.

This historically has been a hotly debated topic (lets not replay that now - although we might want to discuss it in Atlanta). The two points of view basically are this (1) advanced users *really* like the ability to pop back and forth between things and take a quick look at another tool while in the middle of something in their main too and (2) this confuses the HECK out of beginning users - they never find the reset button.

Sadly - both of these arguments are pretty good. The notion of state saving across navigation kind of comes form the "portal" world where there are multiple tools on a page and interactions with one tool do not change the state of another tool. Effectively you *had* to save state when multiple portlets were active (especially on the same page). Hence state saving as default throughout the life of Sakai so far.

We had always talked about an "option" because there was such strong (and valid) disagreement. For 2.3 there will be just such an option:

portal.experimental.auto.reset=true

We will ship with the default turned off - kind of like a provisional feature. The feature works and is very clean - it only affects the portal code (Charon) - there are no changes to tools or filters or any part of the Sakai framework. This is literally "reset tool state" when navigating back to a tool. Frankly, if folks really felt strongly this is so clean it could be a personal preference - but that is another debate entirely.

I would like folks to use this and experiment with this.

This could be easily back-ported to 2.2. With some effort it could even go back to 2.0 and 2.1 (commits 14687 and 14596). All of the modifications were done this week. I am not going to do these back ports - I need to get back to marketing Sakai - Integration week has been fun but I don't have the luxury of coding much any more.

Looking forward - I think that we need to get community reaction about how to go forward - I am sure the discussion will be lively. I see a few diffeent directions this might take (debate over the default - always fun and debate whether or not we make this a personal preference).

I also think that as we move towards JSR-168 and an even more "portlet view" of the world, we might need to revisit this again so as to properly fit into portals.

Nothing is simple - but at least for now we have options.

iFrames and state reset - Journey to the Kyper Belt

I have not read much mail last few days. Ian, Glenn and I were on a mission to explore strange new interplanetary planetoids. Here are some notes. They are boring.

includeTabs

doGalleryTabs
includeTabs(out, req, session, siteId, "gallery", false);

doSiteTabs
includeTabs(out, req, session, siteId, "site", false);

includeGalleryNav
includeTabs(out, req, session, siteId, "gallery", false);

includeSiteNav
includeTabs(out, req, session, siteId, "site", false);

line 2261

includePageNav called once by includeWorkSite

doGallery
includeWorksite(out, req, session, site, page, toolContextPath,
"gallery");

doSite
includeWorksite(out, req, session, site, page, toolContextPath, "site");

doWorkSite
includeWorksite(out, req, session, site, page, toolContextPath,
"worksite");

Free Converter to Produce Flash Video on the Mac

I am trying to get to a 100% mac production of video and It seems as I have done it.

The last bit was how to encode Flash Video on the Mac. It seems idiotic to pay $900 to Adobe just to encode some MPEG. Here is the solution:

http://www.ffmpegx.com/download.html

Follow the instructions.

My first experiment was fine but there seemed to be some discrepency regarding the length of the video - the scroll bar was wrong. Riva encoding the same material seemed to get it right. But for new it seems workable and not having to add a PC to the process just to make FLV is a big step forward.

Take a look at:

http://www.dr-chuck.com/media.php?id=65

To see the results of the new process.

This was shot with the new(for me PD100) camera and edited on the way back across the Atlantic on an Airbus A330. Tres cool. Like they said in the instructions I had to remove the battery- it did not have enough amps for both the computer and the battery.

Also note that this *will* recode RealMedia - Hmmm. Perhaps it is time for me to co and recode all of my old clips in a more portable format.

How to make an All Hands Group in Sakai

Welcome to the experimental All Hands provider.

The goal of this code is to allow the creation of Sites in Sakai in which
all users are automatically added.

The basic idea is to make an external group provider id called "sakai.allhands" and then either produce a GroupProvider that indicates that all users are members of that group or add the code to an existing group provider.

If you have an existing GroupProvider, simply add the following line of code:

public Map getGroupRolesForUser(String userId)
{
Map rv = new HashMap();

rv.put("sakai.allhands","access"); // Add this line

return rv;
}

If you do not currently ave a GroupProvider, use the AllHandsGroupProvider provided herein.

To enable this group provider, simply edit the file

component/src/webapp/WEB-INF/components.xml

And add a bean entry as follows. Redeploy your Sakai and Viola!

class="org.sakaiproject.provider.authzGroup.AllHandsGroupProvider"
init-method="init"
destroy-method="destroy"
singleton="true">

There are print statements in the code so you can be confident of that is happening. Remove those statements before you go to production.

HOW TO USE THIS

Make a new site. Either Setup or WorkSite Setup can be used.

Log in as Admin. Use the Sites Tool to find the site you just added. Grab the site ID using copy.

Go to the realm's tool and past in the site ID and press "search" you will find the
realm associated with the site.

Click on the realm - In the field "Provider Id" Enter "sakai.allhands" (no quotes) and save.

Now as people are logged in they get added to this site as "access". If you change someone to maintain - they keep maintain.

WHY THIS WORKS?

When the user logs in, as part of their login the provider method

getGroupRolesForUser(String userId)

The real question being asked here is "For this user, what is the list of Provider IDs does this person belong to and what roles does that user have for each ID". We indicate that "for all the sites with sakai.allhands the current user deserves access". So authzGroups above us does magic SQL to make this so it looks for all of the sites with the provider ID "sakai.allhands" and simply pokes the user into those sites.

Look in this file:

authz-impl/impl/src/java/org/sakaiproject/authz/impl/DbAuthzGroupService.java

Line 1554 to see the fun:

// for each realm that has a provider in the map, and does not have a grant for the user,
// add the active provided grant with the map's role.

/Chuck

Sat Sep 9 00:34:37 CEST 2006

Unrelated nerdy bits - ignore - they are just notes regarding an approach that I did not follow through with because the trivial solution presented itself.

authenticateUser() userId=usera
getGroupRolesForUser() user=user1
getUserRolesForGroup() id=null
getUserRolesForGroup() id=null
getGroupRolesForUser() user=admin
getUserRolesForGroup() id=null
getUserRolesForGroup() id=null
getUserRolesForGroup() id=sakai.access
-- Really this is get the map of users and roles for this group

getGroupRolesForUser() user=admin
getGroupRolesForUser() user=user1
^C

authz-impl/impl/src/java/org/sakaiproject/authz/impl/DbAuthzGroupService.java

// Simple serialization of the existing grants. A HashMap with each entry a list.
// keyed by user ID
Map grantMap = new HashMap();
for (Iterator i = grants.iterator(); i.hasNext();)
{
UserAndRole uar = (UserAndRole) i.next();
List values = new ArrayList();
values.add(uar.role);
values.add(new Boolean(uar.active));
values.add(new Boolean(uar.provided));
grantMap.put(uar.userId,values);
}

authz-api/api/src/java/org/sakaiproject/authz/api/GroupProvider.java

/**
* Access the user id - role name map for all users in the external group.
*
* @param id
* The external group id.
* @param grantMap
* A hash map keyed by userId. Each entry in the map is a List with three elements
* String current role in site
* Boolean active
* Boolean provided
* @return the user id - role name map for all users in the external group (may be empty).
*/
Map getUserRolesForGroup(String id, Map grantMap);

"authz-impl/impl/src/java/org/sakaiproject/authz/impl/BaseAuthzGroupService.java" line 818 of 1448 --56%-- col 4-25

"authz-impl/impl/src/java/org/sakaiproject/authz/impl/DbAuthzGroupService.java" line 1473 of 2069 --71%-- col 35-49

// for each realm that has a provider in the map, and does not have a grant for the user,
// add the active provided grant with the map's role.

"authz-impl/impl/src/java/org/sakaiproject/authz/impl/DbAuthzGroupService.java" line 1554 of 2069 --75%-- col 5-33

Roskilde Visit

Today I am at Roskilde University in Denmark. My goal is to talk with the folks here and then to make a video that looks at the way Roskilde integrates Sakai into their very unique group riended curriculum.

A cool idea came up in a meeting - "tiny URLs" for resources in Sakai. Here is a basic design. (a) Make a TinyURL service which takes a long URL as a parameter and returns a short URL - storing the mapping between the tiny url and long URL in a simple two column table. (b) change the getUrl method in

content/impl/src/java/org/sakaiproject/content/impl/BaseContentService.java

To consult the tiny URL service before returning the URL and return the short URL.

(c) make a simple servlet - lets call it /s that simply looks up the tiny URL and does a redispatch to the tinyurl's destination. I think that we could ignore all of the servlet filtering in this first servlet and let the destination do whatever it likes. Perhaps a redirect would be better - but smarter people than me need to decide if a redirect or redispatch is better. What does tinyurl do? So Sakai tinyurls look like:

http://x.y.z/s/FaeD12/

Of course this behavior would be controlled by yet another property because it would have a performance and storage impact as it would require some look up on each URL in the display of a resources page - some basic caching should be done - could be quite simple because the mapping is read only and no mapping is ever deleted.

Lubeck Report - EU-Sakai

Having a great time here in Lubeck. Here is some cool philosophy.

Rolg Granow who is the Managing Director of OnCampus (or hosting organization for EU-Sakai) madesome really cool points as to why Lubeck was attracted to Sakai:

(1) It is an exteisible framework

(2) It is a reasonable tool in terms of covering the basics

(3) Sakai is not yet complete - so Lubeck (and others) can help define Sakai going forward

He feels that we have only scratched the surface on eLearning and we need to explore some really new things and one of the problems with something like Moodle and commercial alternatives is that they are *too mature*. They have figured out what they are and do a nice job of implementing that. It is harder to affect Blackboard or Moodle because of the maturity of the product.

I agree that Moodle and Blackboard are more polished than Sakai - but this is the first time - that it seems to be a positive for Sakai rather than a negative :)

Another wonderful point that Rolf made is that we need to find ways to diversify the population of our students in classes - Lubeck collaborates around the Baltic sea, and with others around the world.

Instead of using the Internet to get geographically distributed people to receive the courses regardless of location - his philosophy is that learning the future will need to bring together courses with students from multiple countries and cultures *together* (regardless of geography) for a single class.

They have initial results that culturally diverse courses help students learn better. Up to now distance education is simpy a way to let people take classes while working or on some remote location. Rolf's hypthesis is that these technologies bring a culturally diverse student population *together*.

This fits nicely with some of Joseph Hardin's ideas that "open courseware" is not about producing something and "exporting" it but instead to create a rich global community that both produces and consumes materials some of which are globally contenxtualized and other elements which are highly localized. Joseph's notion is that we learn best from contextualized learning.

Combining Joseph and Rolf' hypothesis - we benefit both from contextualized learning as well as participating in learning that is cross-cultural.

Software Patents for X-First Routing in Mesh-Based Supercomputers

This is an idea that solved a seemingly intractable problem with mesh-based multi-computers. In the late 80's and early 90's folks were experimenting with ways to build large multi-processors using a physical grid as the interconnect - Intel supercomputers use this approach. The idea was that the connection was like city streets laid out on a grid and that the messages would zig-zag around the streets like taxi's. Many approaches were tried and under heavy traffic they got deadlocked. It was just like in a big city when traffic backs up and blocks an intersection and that that traffic is also blocked by other traffic - we call it "gridlock" when applied to traffic. Many people tried to figure out how to solve this with really complex approaches to the deadlock problem. It was very difficult and very hard to prove that many of these approaches were deadlock-free.

The actual *Innovation/Invention* (as distinct from the patents)

A short version is that around 1990, Michigan State University student Christopher Glass was working on his thesis and wondered if a very simple approach of making the messages go as far in the X direction as they could before making a turn into the Y direction. This was deadlock free and provably so - and much easier to implement in hardware than any of the other approaches previously proposed.

This is a brilliant idea and an innovation that will save people money. I don't believe this was ever patented or even applied for by the "inventors". All they did was got a thesis, wrote a zillion papers and got some NSF grants.

References:

http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=514204
ftp://ftp.cps.msu.edu/pub/crg/PAPERS/msu-cps-acs-33.ps.gz

If you are curious as to the very novel and revolutionary idea really works and why it is provably deadlock free, see this document - and read pages 6-10.

Someone did get a patent: 7,072,976 (Go to http://patft.uspto.gov/netahtml/PTO/srchnum.htm) - This patent was filed January 4, 2001 and granted July 4, 2006.

But if you look at this patent, it references tons of prior art - including academic work from over a decade earlier - including the paper I reference above.

Since in software patents - only a jury can interpret a patent - who cares what my opinion as an expert in the field is. Just try to read this patent yourself and form an opinion as to whether this was novel or not and you will see why jury trials in many software patents are a joke.

Note: None of this story is intended to imply anything bad about Lee S Whay. The reality is that ideas were coming fast and furious in this field in the late 80's and early 90's - everyone Lionel Ni, Bill Dally and others were just writing inventing and publishing as fast as they could. I am a personal friend of Lionel Ni and through that relationship in the 1990's I knew of their innovation and papers. This is not about getting credit where credit is due. I think that Lionel would be very very pleased that his work was referenced in these patents. Please do not think this is about any tension in the situation I am describing - look in the conclusion - this is about patents - not this particular idea. Also - no one did anything wrong in this story - to the contrary - everyone in the X-Y routing saga is being 100% forthright and honest. I just so happen to have special knowledge about this particular idea and how it was discovered and published so it is easier for me to research the evolution of this idea in the US Patent Office.

Cold Case Detective for X-First Routing

Lets see how this X-First Routing idea travelled through space and time and ended up in a patent.... First some background research - print all this stuff out and make a binder if you want to be a detective with me.

Go to this URL:

http://patft.uspto.gov/netahtml/PTO/search-adv.htm

Enter these searches:

IN/Lee AND IN/"Whay S" (A search for all the patents filed by Lee S Whay)
"lionel ni" (Searches for all patents which mention Lionel Ni)
IN/lionel AND IN/ni (A search for all the patents filed by Lionel Ni)

Also go to the URLs of the players in our little drama:

http://cva.stanford.edu/people/wslee/ (The guy now working at Sun who filed all the patents)
http://www.cse.ust.hk/~ni/ (The thesis advisor of the guy who did the innovation)
http://cva.stanford.edu/billd_webpage_new.html (The *top* guy in the field and Lee Whang's mentor)

Timeline -
1991 - Working for Lionel Ni, Christopher Glass "Discovers X-First routing" and publishes a sweet paper
1993 - 1998 Lee Whay seems mostly interested in microprocessor Architecture - working with luminaries like Bill Dally at MIT and then Stanford
199? - 1999 Gets Phd at Stanford - Mechanisms for Efficient, Protected Messaging - Awarded February 1999
March 9, 1999 - Lee makes a presentation at SUN
2000 - Lee Whay starts filing patents for Sun starting with 6,510,050 - The initial topic seems to be storage arrays and then he moves into message passing.

Here are the patents where Lee S Whay is an author *and* Lionel Ni is mentioned in the prior art.

6,718,428 Storage array interconnection fabric using a torus topology
6,741,561 Routing mechanism using intention packets in a hierarchy or networks
6,826,148 System and method for implementing a routing scheme in a computer network using intention packets when fault conditions are detected
6,883,108 Fault-tolerant routing scheme for a multi-path interconnection fabric in a storage network
6,925,056 System and method for implementing a routing scheme using intention packets in a computer network
7,000,033 Mapping of nodes in an interconnection fabric
7,027,413 Discovery of nodes in an interconnection fabric
7,072,976 Scalable routing scheme for a multi-path interconnection fabric

Lionel Ni is mentioned in 17 patents 8 of which were filed by Lee S Whay. Lee S Whay filed 19 patents of which 8 reference Lionel Ni as prior art.

Conclusion and Summary

So lets cut to the chase: Is Lee S Whay a bad guy for filing a ton of patents closely related to other people's work and claiming that it was innovative?

Answer: Absolutely not! Lee was 100% honest in every patent he filed - he had been a thorough student and knew the field intimately for nearly ten years before he filed his first patent. His patent applications are magnificent summary of prior art both inside of the patent arena and inside of the academic arena. His last patent 7,072,976 references 53 patents dating back to 1989 and 27 academic references that include the "who's who" of seminal breakthroughs in the mesh routing. His references suggest that he not only knows the field but knows the individual innovators as well.

Why - because these patents are just follow on work to his Phd. Thesis at Stanford. To get a Phd - you must know what has gone before and you must prove innovation beyond the prior work to a committee of arguably 5-6 of the top 100 researchers in the field - for Les S Whay - I am guessing the Bill Dally was on his committee - Sheesh. Once you past Phd. muster at Stanford with Bill Dally on your committtee, a patent examiner is simply coasting downhill.

I know this field (or at least knew it in the early 1990's) - If I were a patent examiner and sitting across the table from Lee S Whay - and reviewing patent 7,072,976 - I would give him the patent - even though I *HATE HATE HATE* software patents in general.

I would have granted patent 7,072,976 because I knew that this patent was useless as an offensive patent - completely useless. Because Lee S Whay had the integrity to reference all the prior art he knew of - he made it easy for a patent defense lawyer - to fight against this patent. In effect these patents openly and readily admit that whatever innovation is being proposed is a "tiny improvement" on what has gone before.

As a matter of fact, the law states that Lee S Whang *had to* reveal prior art he know about (from http://www.bitlaw.com/source/37cfr/1_56.html) - or the patent would have been invalidated:

".... Each individual associated with the filing and prosecution of a patent application has a duty of candor and good faith in dealing with the Office, which includes a duty to disclose to the Office all information known to that individual to be material to patentability as defined in this section. ... The Office encourages applicants to carefully examinethe closest information over which individuals associated with the filing or prosecution of a patent application believe any pending claim patentably defines, to make sure that any material information contained therein is disclosed to the Office. "

So Lee S Whang - revealed all the prior art he knew about. If he did not list the Ni work a decade earlier - there is no way in this world that he would have been "caught" - because he was an expert - he could hide evidence as easily as reveal evidence. But he revealed *all* the evidence and *still* made his case how his patent claims were an innovation in the light of the great body of prior art.

By acknowledging the real body of prior art work two things happen: (1) the patent examiner has some chance a determining novelty and (2) once approved - the work of Liolnel Ni has far less "shock value" when presented in court against the Whay patent - Whay and his attorneys simply say, "of course we knew about your work Dr. Ni - we listed it in the patent - DUH!!!".

This combination of a completely honest assessment of prior art *and* a simple and clear innovation that goes "a little beyond" the prior art results in the perfect defensive patent on Sun's part. This patent would e *very very* useful in case Sun wanted to build a mesh based interconnect (perhaps for storage arrays) and wanted to use X-First routing.

What if some small piss-ant company like NastyChuck, Inc went and filed a patent in 2006 on X-First routing because I knew Lionel and realized today that Lionel *never* filed a patent on it and then I went to sue Sun and Intel - Sun and Intel would have plenty of patents to trounce me.

Lee S Whang has placed solid evidence in the public patent record that this innovation is "sort of covered" by a Sun patent - but more importantly if I search and find the Sun patent - I will be led directly to the much earlier public record of folks like Bill Dally and Lionel Ni in the early 1990s that made all these innovations wildly public.

So Lee S Whang (and Sun Microsystems) has done us all a great service - Lee effectively went in and used his intimate knowledge of the Mesh routing area to create an interlocking web of patent filings around message routing. Sun will likely never make a penny off these patents - but more importantly no one else will. And most importantly of all no company will be able to get a "win-the-lottery" patent and stall innovation by holding the real innovators hostage.

With a patent office that pretty much will approve anything for a software patent as long as the margins are the right width - and a jury system in western Texas that is so wise that it can support the patent holders claims without even reading the patent - honest and decent people have no choice but to "clog the system" with these pre-emptive defensive patents. But very importantly - for this to work - those patents need to be *honest* and truly refer to the true prior art across both the patent field and the academic publication world.

Thankfully Lee S Whang had his training in solid academic programs (MIT *and* Stanford) and the top mentors in the field (Bill Dally) and had the importance of "academic integrity" as part of his entire education. Now that he works for Sun - he still "tells the whole truth and nothing but the truth" and makes sure that the work that he does for his company - while it is beneficial to his company - it also has integrity - because it has his name on it too. Conveniently it also is the right thing to do according to Chapter 37 of the code of Federal Regulations (http://www.bitlaw.com/source/37cfr/1_56.html).

So what does this have to do with Patent 6,988,138

Patent 6,988,138 references twelve other patents and zero non-patent documents as the patent applicants assessment of the prior art for the patent.

Here is a list.

5263869 May 1991 - Interactive Communication Systems, Inc. (Milwaukee, WI
Interactive group communication system (basically instant messaging by going into a lab and using computer terminals)

5437555 August 1993 - Discourse Technologies, Inc. (Milwaukee, WI)
The notion of distance education - A computerized teaching system is described including an interactive group communication system, wherein students interact with a teacher and the teacher can obtain quantitative reports on student performance without preprogrammed lessons and where a lesson program can be constructed from the responses of the students.

5537141 April 1994 - ACTV, Inc. (New York, NY)
Distance learning system providing individual television participation, audio responses and memory for every student

5918010 February 1998 - General Internet, Inc. (New York, NY)
Collaborative internet data mining systems

5973683 November 1997 - IBM
Dynamic regulation of television viewing content based on viewer profile and viewing history

6301462 June 1999 - UNEXT.COM
Online collaborative apprenticeship

6334141 February 1999 - IBM
Distributed server for real-time collaboration - Effectively Instant Messaging

6338086 - June 1998 - Placeware
Collaborative object architecture - "..Collaborative objects allow ubiquitous sharing and provides each user with the same copy of the shared object. Optimistic concurrency control allows full-duplex group editing and natural interactions.."

6347333 June 1999 - UNEXT.COM
Online virtual campus - This one is a bit interesting - I don't exactly understand how 6,988,138 in its final form is novel beyond this patent.

6463460 - April 1999 - The US Secretary of the Navy
Interactive communication system permitting increased collaboration between users (shared whiteboard) software

6505031 - February 2000 - Slider; Robert (Longwood, FL), Robinson; Michelle L. (Longwood, FL)
System and method for providing a virtual school environment - This is getting close to 6,988,138 but it mentions parents so it is kind of K12ish.
Slider et al.

6546230 - December 1999 - General Electric Company
Method and apparatus for skills assessment and online training - Competency tests are stored on machine readable media and transmitted via network connections to remote provider systems, such as workstations or diagnostic systems

Final Words...

The summary here is that according to the filing of patent 6,988,138, on June 30, 2000 - based on what the inventors of this idea knew - the use of technology in education was pretty darn weak - there was barely any prior art.

The only thinge the inventors remotely about "a plurality of courses on a server" were: (1) Some dudes go into a lab in 1991 and use computers to talk - (2) in the early 1990's we send classes out on TV sometimes - (3) sometimes we chat with students - (4) we use white board software some times - (5) we can send stuff to parents of K12 kids using software - (6) we can send people tests at remote locations - and (7) some of those tests are about competency.

Boyer-Moore Search - An Innovation that Deserves a Software Patent

From: http://en.wikipedia.org/wiki/Boyer–Moore_string_search_algorithm

"The algorithm preprocesses the target string (key) that is being searched for, but not the string being searched. The execution time of the Boyer-Moore algorithm can actually be sub-linear: it doesn't need to actually check every character of the string to be searched but rather skips over some of them. Generally the algorithm gets faster as the key being searched for becomes longer."

The Boyer-Moore string searching is like free beer. Unlike most string searching approaches it is sub-linear and improves as key length increases.

Lots of patents are filed related to this innovation - go to http://patft.uspto.gov/netahtml/PTO/search-bool.html and enter "Boyer Moore".

I particularly liked patent 6,768,991- July 27, 2004 (Searching for sequences of character data - Hearnden; Stephen Owen (Great Holm, GB) - Networks Associates Technology, Inc. (Santa Clara, CA)) - This patent does not try to patent Boyer Moore itself - but at least they are honest about the 30 year old prior art upon which their work builds. In summary the patent is "we used Boyer-Moore to search E-Mail!".

But here is the key idea - Boyer and Moore *did not* patent the idea - the *real* innovation - they just published it. This essential "free" idea has led to tons of innovation (withness all the other patents) or type Boyer-Moore into Google.

What would have happenned if Boyer-Moore filed and received a patent? That would suck.

But what happens is a *lot of people* with less talent than Boyer or Moore had in their little fingers - have filed a ton of patents touting their *use* of Boyer-Moore. I guess that this makes people feel good and makes sure that no one else can file such a silly patent and attack them. Such is the nature of software patents.

To me this is like inventing the "color blue" but not patenting it and then having lots of people patent "I made a picture of a lake and used the color blue - Eureka! - give me a patent on the use of the color blue in paintings of lakes.".

But since the USPTO gives out patents for "I saw this cool idea and used it" -you need to file defensive patents all the time. Grrr.

Dang - I should have *patented* the use of asterisks to indicate emphasis within a blogging system stored in MySql on a plurality of servers!

Chuck's Patent Attempts

Over the years, I actually have come up with a zillion ideas for "things" that I wanted to patent. Sometimes later those things would turn out to be commercially valuable and I kick myself later. Other times those ideas never panned out.

One of my oldest patent ideas was many years ago when we all started self-service gas stations (yes a long time ago). I kept jamming my gas cap into the handle so I did not have to hold open the gas while fueling. I figured that a well-designed "H-Shaped" piece of plastic would do the trick much better than the gas cap which was round and kept popping out. You could put logos on it and sell it for a buck - all I wanted was five cents for each one sold! Like the pet rock, this seemed like a sure way to get a nice steady income.

So I went and talked to a patent lawyer at the university I was working at the time and pitched the idea - after all - they would do all the paperwork and we would share in the profits.

The patent attorney sat down with the bright 20-something kid and did everything he could to try to blow a hole in my patent using prior art - he suggested that such a thing might already be patented to hold windows up, or used to keep multiple items separate while shipping or even be part of a screen-door patent. Pretty much he told me that it was very very unlikely that my idea was novel and that after we wasted all the school's money on the application we would lose. He even went so far as to say there was no market for the device.

Dejected and rejected I gave up trying to patent my ideas - the prior art barrier was just too high - I could not even get past the first "freely provided" attorney.

I wonder of course, if I had been paying the attorney if the conversation would have been quite different - right now - I would live in a mansion and you all would be using your "Chuck Pumper's" emblazoned with Nascar logos and right next to the counter at all the best gas stations in the country.

So my more recent approach (now that we have the internet) is to just blog my patents. At least when someone makes a killing and files a patent - I can say to my friends - see I patented that years earlier on my blog.

My most recent blog-patent (Feb 2006) is retractible iPod earphones and a slightly redesigned iPod shuffle. I have a picture and everything.

Why Patents *work* for Things

So here is the key notion - each of these two ideas are describable. You can look at my 200 word descriptions and a cell phone picture picture and (a) quickly understand what the invention *is* to the point where you could design and manufacture the invention and (b) instinctively know if you infringe on my patent or (c) quickly know if your prior patent or invention blows me out of the water.

These are *widgets* - describable things - the things that the patent office is trying to empower invention and innovation to allow these ideas to be revealed as early as possible (think how much better a world this would be if I revealed my pump-o-matic in the 1970's - but without a patent I kept the idea hidden for over 30 years). Patents are designed to encourage the revealing of the innovation and establishing a publicly validated (sort of like a government-sanctioned blog) time when the innovation happened.