Chuck Hedrick (one of the Sakai community’s superstars) is always way ahead of our ability to integrate patches/features. This is great because it leads us to figuring out how to handle materials coming from a broad community. This will knock out the cobwebs in procedures that we don’t yet have.
But this is really pretty simple. Chuck H is not waiting for everyone to give him permission to move forward – he is just doing it. Since there is no paid system integrator in the Sakai foundation, we just have to get folks to work togther and try to get the community to render opinions on stuff so stuff can move forward.
In a way, since IU, OSP, and UM are doing most of the work in this area, they need to get involved to make sure these modifications are good and worthy to drop into trunk. Now IU and UM are just volunteers like Rutgers, but IU and UM are the “leads” in the areas that Chuck H. is working so they need to respond to these patches in some timeframe.

Some comments on these patches.
On Jan 7, 2006, at 12:27 PM, Charles Hedrick wrote:
We’ve started moving to 2.1. We’re starting to move the Rutgers patches listed in Jira 2505 from 2.0.1 to 2.1. Other Rutgers staff will do most of this. I’m doing AccessServlet. It’s been refactored, so most of the changes to into BaseContentService.java. Because I’m giving you only the changes to those modules, some feature are only half there. They depend upon changes to other files, which will have to come from other people. [However I believe that they can be easily adapted from the 2.0.1 patches, which you can find from Jira 2505.]
These changes are in a tar file attached to Jira 3442.
Implements 4 features. (These features are completely implemented by this patch. See below for the ones that are partly implemented.)
1) Aliases. If you create a mail alias for a site, you can access its resource section with the same alias, e.g. http://server/access/myalias
2) Content view. If you access a folder (as opposed to an individual resource) via /access/content, normally you get an error. With this patch you will get a directory listing in a format that is appropriate for end users. It shows the description of the folder and each item, so it looks a lot like a Melete organizer page.
3) If you specify ?basedir=xxx or ?sbasedir=xxx [for Sferyx], directory listings have a special format intended to support pick lists in HTML editors. Our users want to be able to insert images easily in HTML. Part of that is for the HTML editor to be able to show them a listing on their /images directory and make it easy to pick an image. This is the server side of that. The basedir format should be easy to use in any Javascript code. The sbasedir format is tuned specifically for Sferyx’ file picker.
4) implemented file upload via HTTP POST operations. This is also intended for HTML editors, to let them upload images. Sferyx uses this technique, and I believe other HTML editors do as well.
I feel that these modifications are effectively upwards compatible and add good features that cause no harm to any of the current ways that code works. I would like to simply move these patches into trunk so Chuck does not have to maintain these. But I would like to hear from others who like these patches or think that these patches should not just become part of Sakai.
These features need documenting. We need a document ~dev/sakai/docs/architecture/sakai_access.doc that describes these features of access servlet in a style similar to the other documents in this directory. There is not a current document on access servlet so one should be started. To me documenting these features for posterity is an important aspect to getting these features into the code base. The simplest would be for Chuck H to write up the document – if not it will wait until someone else gets around to writing the document. I don’t want to hold up the progress on moving this to trunk with a demand for documentation – but it is a strong desire that we don’t go too far without writing the internal developer documentation so that folks can use these features. It is always easier to write up basic documentation while things are fresh in people’s minds.
Interaction with other patches. I don’t yet have 2.1.0 versions of our other patches. However I believe the 2.0.1 versions may port fairly easily except for this patch. (This one was hard because AccessServlet was refactored for 2.1.0.) See Jira entry 2505 for a list of our 2.0.1 patches.
1) Users without write access to resources are prevented from seeing inside a directory whose name starts with “protected.” Other parts of this feature are in ResourcesAction.java, chef_resources_list.vm, chef_resoures_newlist.vm. If you don’t want this feature, look for “protected” (with the quote marks) in BaseContentService.java, and remove the whole paragraph (surrounded by blank lines).
This feature is something that needs to be discussed. Security by naming convention is a quick way to add a feature but can result in brittle code. Chuck H – lets keep this one separate and keep talking about this. My concern with this feature is its design approach from a technical level – so we need to keep working on this.
So I would suggest that you make a separate JIRA item – call it something like “Adding protected folders and files to Content Hosting” and publish a patch. Perhaps this is best done as a requirement because it really is a request for new feature which also happens to have a patch.
2) Users can change the order of entries in resources. This patch uses the proper order in displaying directories, but ResourcesAction and the vm files [same list as (1)] need to be changed to let the use change the order, and to use the proper order in the Resources tool.
I think that this is a feature that many would like. I would also like to keep this patch separate from the others. My concern here is two-fold – first we need to look at how this is done storage-wise and whether the approach used for storage of the ordering information will perform at scale (we had a performance problem on the first implementation of tab ordering). The second concern I have is the user interface. Lots of people have opinions about how the Resources user interface is supposed to look and when the resources tool user interface is changed we need to get a lot of eyes on the proposed changes. So before we go forward on this I would like to see some kind of design proposed and made available for folks to look at.
We don’t really have a good “procedure” for how we do this “hey take a look at this design” and give comments. I would propose that in lieu of waiting for a formal process that we come up with a confluence page which takes some screenshots of the current modified tool running at Rutgers in 2.0, add some descriptive text and get some discussion around the changes so we can get some agreement from the Resource tool stakeholders before going forward.
I would also suggest that you make a separate JIRA called something like “Ordering items in the Resource Tool” and publish your patches here for folks to play with. Also entering a requirement would be a good idea. Perhaps this is really just a requirement…
As Jim Eng has said separately this code (Resources Tool) is a real moving target right now. The end-user interface is not changing much at all, but it is being re factored in terms of *how* things are done internally for 2.1.2. It is going from a monolithic tool to a set of cooperating helper tools. SO expect that you will have to end up with a 2.1, 2.1.2, and possibly even a 2.1.1 version of this patch. Chances are good that the code won’t change too much (similar to the Access Servlet refactor above) but it will be in different places and different files.
Since you are deploying 2.1 – the only patch that matters for you is the 2.1 versions of the patch (for now).
—- To the community —-
We all have a responsibility to take a look at these modifications – one of the best ways to know that folks “like” a particular patch and that the patch is high quality is for more than one site to successfully run it in production. This pattern worked very well for things like the SU tool – since several sites had already run it successfully it dropped into the release with barely a ripple. So I will be looking for some community reaction to and investment in these patches. If community simply say “yes do them all”, that is fine input, but the speed at which these patches move forward depends solely on when folks from IU and UM have time.
It is much better input when the folks in the community say “I ran all of this in production for several months – it ran fast and reliably and my users loved it”. :)
—- Summary —–
Please separate this into three thrusts.
The Access Servlet stuff can likely fold in nicely to trunk – I looked this code over in 2.0 and actually tried to get it into 2.1 but ran out of time – since the Access code refactor is already done in 2.1 – your patches should be solid for all 2.1 and 2.1.x versions giving us time to get them into trunk so you don’t have to separately maintain these.
The ContentHosting stuff has some design issues. Keep it separate – use it at Rutgers – when we get some time, we need to talk about the right way to do this for the long term. This should probably become a “requirement” where the need is expressed in end-user terms.
The Resources tool ordering just needs some eyes to look at the GUI changes and “sign off” – this code is in the midst of refactor so keep these patches nice and separate and expect to have to keep moving the patches around through 2.1.2 – work with Jim Eng and perhaps we can smooth out some of the refactor bumps. At a minimum, since Jim knows about these patches, Jim can let you know when things have settled down so that you can work together to make the patches work in 2.1.2 while the refactor is fresh in Jim’s mind.