> > > In this email we outline concerns about the current choice of client > architecture for SCY-Lab. The email represents the views of > University of > Oslo, Intermedia and Enovate. > > > > Concerns about the Java-based solution on the Client side for SCY-Lab > > We would like to come with some comments based on the discussions > that have > been a part of the recent developer online meetings. > > It is important to decide upon a platform for SCY-Lab. The tools to be > developed are strongly dependent on the technological platform that > they > have to be integrated with and work from. The platform for the SCY-Lab > influences how the tools are programmed. Since the design, > development and > implementation of the tools have been started it is of uttermost > importance > to come to an agreement on the technology to be used in the commmon > SCY-Lab. Spending time on tool development without having a common > platform > first may make it difficult to integrate the tools in the end and > may also > extend the programming time considerably. If possible we should > attempt to > avoid this. > > Currently there are two prototypes for SCY-Lab namely GWT (known > from Bonn > meeting) and a new JavaFX based (based on Jacob's ELO browser). > Current > trends indicate that the SCY-Lab client is planned to be a Java > solution. > As far as we understand, SCYLab will be the main component that will > run > all other embedded SCYComponents either inside a web browser as an > applet > or as a Java webstart application. This means that all users have to > open a > Java-based tool in order to run any SCY-component. > > We are concerned with the likely choice of using a Java based > solution as > the main architectural component on the CLIENT side. All the current > requirements in the scy-stylebook can be fulfilled by using a java- > based > solution. It has been excellently demonstrated in Jakobs ELO- > browser, but > the requirements can also be fulfilled in a browser-based solution. > In this > document we first outline our concerns, then propose a browser-based > SCY-Lab solution. In the end we argument for why a browser-based > solution > might be better for the project and its partners. > > Concerns > > As from what we can read from the SCY-Stylebook it seems that a java- > based > version of SCY-Lab will be able to cope with the general aspects of > the > requirements. Presenting a graphical navigation area, presenting > ELOs in > different ways and manipulating these will all be possible by using > the > java-based approach. A java solution will be able to present a look > and > feel of the SCY-lab as presented in the drawings in the style book. > It is > when we look a bit further that we start to see potential problems. > These > are as follows: > > 1) When starting up the current version of the elo-browser > (http://gw-sikkenj2.gw.utwente.nl:8080/roolo-mock-server/) we see > that on > our computers this is a really heavy application that is started. It > takes > quite some time to load, and processing is quite intense when the > applet > starts up. This is a well known fact about java applets. We are > concerned > that this may turn out to be a problem when this application is > going to be > run in schools. If a group of 15-20 students startup this > application on a > thin client cluster this will potentially represent a big bottleneck > for > the system. It may even turn out that the system cannot run because > of the > high processing demands. When the applet has started up, processing > requirements seem to be quite low, and the applet runs smoothly. So > startup > of the application seems to be the main bottleneck. We acknowledge > that the > processing capability will be improved very quickly. It is true that > in a > few years the startup may not be bottleneck anymore on a state-of- > the-art > processer. However, we must remember that schools usually do not > have the > state-of-the-art equipments. > > 2) The java-based SCY-Lab will have challenges running applications > that > are written in other languages than java. We are at this stage not > even > sure whether if we can run Flash applications within it or not. We > know > there are solutions, open source and commercial, for running flash > through > java clients, but we are still not sure how well these will work, how > accessible they will be for schools and whether they can satisfy the > needs > of the application programmer. HTML-based applications will be > possible to > run from the java client, but they will require special handling in > order > to be embedded. Deciding to use Java for the main client component > may thus > rule out several potentially interesting applications for SCY, that > are > written in other languages than Java. > > 3) With a java-based version of SCY-Lab the clients will have to run > heavy > java code. If the client is based on Java, the whole client will not > be > runnable if the clients cannot handle Java. No "light weight" > javascipt/html part of the SCY-Lab can be run as a partial solution. > > 4) JavaFX is currently in version 1.0, which means that we may find it > immature. Using this technology as a technological platform implies > that > all the applications must be adapted to JavaFX and be able to run in > this > applet. Then the JavaFX is the one single point of failure. This > means that > if it fails all the applications in it will fail. Basing the main > technical > platform on a new technology in its first version may lead to > integration > problems with other applications, problems with stability of the > platform > itself and it may also introduce challenges with scalability. > > Proposal--a browser-based solution for SCY-Lab > > In order to provide an open framework where applications can be > embedded > easily we suggest to base SCY-Lab on a plain browser based > framework. Main > elements should be plain html accompanied by javascript. The main > arguments > for doing so are as follows: > > 1) Web-browsers have been built over the years to support plugins of > many > different kinds. Browsers run Flash-, Java-, Javascript-, HTML- > based, etc > applications. This means that nearly any application can be > integrated into > SCY-Lab. > > 2) There are many mature frameworks for javascript that enables us to > fulfil all the requirements stated in the scy-stylebook. These > framework > support advanced rendering, drag and drop, and all the necessary > communication channels that are required for SCY. These frameworks are > constantly developed, open source and have large user communities. > > 3) If we base SCY on a browser based solution, we ensure that > application > writers that prefer writing their applications in Java can do so, > whereas > those that prefer Flash or javascript can do so. The different > applications > can be embedded into SCY based on standard technological solutions, > that we > know already exists. For example, the ELO browser implemented in > JavaFX can > be easily integrated into a web-based SCY-Lab. This makes a big > difference > and will reduce the risk of our further development efforts. > > 4) Applications written carefully in html/javascript are lightweight > and do > not require much processing. If the application framework is carefully > coded, it will run without problems on thin client clusters without > risking > to run down the client system. Browsers are optimized to handle > javascript > and libraries have been written to handle major browser > incompatibilities > that have been the major javascript problem in recent years. > > 5) A client architecture based on html/javascript will be runnable > on most > clients and degrade gracefully if clients cannot run all plugins - > which is > the beauty of the html-based approach. If the client is "light > weight" > with javascipt/html the system will be at least partly runnable on > most > clients. > > 6) The rich functionality provided by the numerous Google applications > (Gmail, Google Docs & Spreadsheets, etc) is an example of how well the > long-lived and established combination of Javascript, HTML and CSS > can be > exploited in new and innovative ways without compromising on > compatibility. > > 7) Last but not least, the current SCY-developer team is composed of > many > different expertises within different programming areas and > languages. This > is a real strength of the project. We should be careful to select a > client > architecture that applauds this diversity of expertise. There should > be > room for both Java-, Javascript- and Flash-programmers to work on > tools for > SCY. If we limit the platform to a Java-based solution, we will lose > the > flexibility and may even lose the possibility to profit from these > different expertises. > > As the team is composed right now, we should build a client > architecture > that enables application developers to collaborate and complete each > others > competencies as much as possible. The architecture should enable > experts > within javascript, html or Flash to be able to work without being > dependent > on a java programmer in order to do their work. This will be > possible in a > careful designed browser-based solution, but we fear that it will > not be > that easy and transparent in a java-based solution. > > -- > ENOVATE AS > Henrik Schlanbusch > Utviklingsleder > http://enovate.no > Tel / Mob.:(+47) 98 25 91 63
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
