[Building Sakai] [Management] Gradebook Situation

Sat Jul 31 01:25:50 PDT 2010

Michael,
If we are really talking about what form of development is acceptable, here is my personal view, which is bound to be shot down.

Its OK for a team of developers to choose their favourite UI rendering technique, its the job of those building the core of Sakai 3 to accommodate a number of approaches (within reason) and recognise that one size does not fit all.

GWT is OK, in-fact its more than OK and we should make every effort to support it for widget development
Server side HTML rendering is OK and we should make every effort to support it for widget development
  on server side we have support for:
     Most servlet based technologies.
     Externally (eg Apache httpd) Hosted scripted, PHP, Ruby, Python, Perl using REST interfaces.
     Sling scripting frameworks, JRuby, Jython, ESP, JSP

Apart from the specifics of the servlet based technologies all of the above is already done in the backend. AFAIK The UI front end does not contain functionality to support server based UI rendering, but I can imagine ways of accommodating it.

There are 3 big caveats in all of this:
   1. If it needs to be in the same JVM as Nakamura, it must work inside an OSGi bundle without doing damage. Spring and Hibernate based framworks don't always work in this respect.
   2. Ideally we don't want a huge number of frameworks as it means that developers cant move between teams with ease.
   3. What the widgets do on screen, should conform to the way Sakai 3 works in a browser, how it does that, is really up for grabs.

------
Internally within the project we are using Rest + HTML/JS, because we believe its the best way of delivering an HTML based app to a browser. We have a long way to go on this journey to get to the performance close to apps like Gmail (which iirc predates GWT and is optimised REST+HTML/JS)

Ian

On 30 Jul 2010, at 20:33, Michael Feldstein wrote:

> I don't think anybody here is proposing to circumvent the managed project structure. I certainly am not. But the reality is that (a) we already have groups developing Sakai 2 functionality that it may make sense to move to Sakai 3 in some process that stops short of complete re-implementation, and (b) we already have groups developing Sakai 3 capabilities that are working outside the structure of the managed project. If the Sakai 3 managed project meets its goals, the number of people and organizations working outside of it that wish to develop and contribute in some complementary way will only grow. John, you have called for groups interested in contributing to join the single distributed team. But remember, there were standards set for participation in the steering committee that not everybody can meet. The idea was that a second circle would be formed in which others could participate without having to commit X number of full FTEs, but as far as I know, that's just an idea right now. In the meantime, development is happening, and it is happening without clear guidance. HEC is doing Sakai 3 development with GWT for sure, and there may be others using some server-side framework or other.
> 
> I see a few options for handling such situations:
> 
> 1. Kick the can down the road. Discourage out-of-band development until the managed project is further along and make a decision then about blessed frameworks.
> 2. Declare now that client-side development is the only kind of development that will make it into Sakai 3 core and let developers working with other UI frameworks decide what they want to do with that.
> 3. Set some early guidelines about which frameworks are adviseable to use and which are not.
> 4. Create that second ring of participation, including mechanisms for coordinating that group with the steering committee, and feed any questions like these through those mechanisms.
> 
> There may very well be others that I'm not thinking of.
> 
> The idea that there would be support for a server-side framework in Sakai 3 is not a new one and I did not make it up. Michael Korcuska brought it up a year ago at the pre-conference working session. Some members of the community are still operating under the impression that this will be the case. I know that I have been. If it is not the case any longer, then that should be made clear.
> 
> It is also important to recognize that this decision has implications beyond Sakai 3, particularly for schools that intend to run in hybrid mode for some period of time (an idea that I am under the impression we are encouraging). Take grade book as an example. Re-thinking and re-implementing a grade book from the ground up is a pretty major undertaking. I would be very surprised (though delighted) if the managed project will be able to deliver a grade book that the majority of Sakai schools would consider to be feature-complete within 12 months. It is entirely possible that even schools using mostly Sakai 3 for their classes will be using Sakai 2 grade book for an extended period of time. To the degree that that is a possibility, and to the degree that we may have community members who need to build 2.x functionality today but want to do what they can to ensure that at least some of their code will still be relevant and usable when their institution moves to Sakai 3, it makes sense to think about what recommendations to make to these developers.  
> 
> If Alan and the Sakai 3 Steering Committee are taking the lead on addressing the question on the table, that's fine with me. The point is, there's a question on the table. It evolved organically out of discussions regarding grade book work for 2.8. It seems natural that, in a world in which there are two products under the Sakai umbrella that are supposed to interoperate at some level, conversations around goals, priorities, and standards for one of those projects may start to bleed into discussion of the other. Nobody was trying to circumvent the managed project or suggest that decisions should be made elsewhere, but at the same time, there needs to be a mechanism for surfacing and addressing boundary-crossing concerns. 
> 
> - m
> 
> 
> -- 
> Oracle
> Michael Feldstein | Principal Product Manager
> Phone: +1 8188172925 | Mobile: +1 9179218895 
> Oracle Academic Enterprise Solutions
> 25 Christian Hill Road | Great Barrington, MA 01230 
> 
> Green Oracle	 Oracle is committed to developing practices and products that help protect the environment	 
> 
> -----Original Message-----
> From: Ian Boston [mailto:ieb at tfd.co.uk] 
> Sent: Friday, July 30, 2010 2:26 PM
> To: David Ackerman
> Cc: sakai-dev sakai-dev; Sakai UI Development
> Subject: Re: [Building Sakai] [Management] Gradebook Situation
> 
> 
> On 30 Jul 2010, at 18:45, David Ackerman wrote:
> 
>> Ultimately, the final decision would be by the Sakai 3 Project Director, Alan Marks. 
> 
> 
> Agreed.
> 
> I hope/expect Alan will make any decisions with input from those who are doing the work based on the results of evaluations aimed at providing sufficient hard evidence to make a decision. When we started Nakamura we spent over 6 months evaluating all sorts of approaches and then spent a further 6 months experimenting with a short list, at every step determined not to repeat and mistakes that we might have made in the past (we even wrote done honest evaluation based on evidence as a aim of the project), and always prepared to start again based on tangible evidence. (Which we did).
> 
> The development methodology we chose is one that is becoming mainstream in web dev, just watch the sessions from Google IO 2009 and 2010 for proof of that, but even so, we are not doing anything that explicitly excludes other approaches.
> 
> I do find it interesting that this discussion is happening here, potentially making decisions and there is hardly anyone from the team tasked with doing the work responding on the list. How about cc'ing the UI dev list for comment ? (done)
> 
> Ian
> 
> 
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"