From: Stefan K. <ste...@eb...> - 2009-06-26 09:19:41
|
On Friday 26 June 2009 08:33:42 Egon Willighagen wrote: > On Thu, Jun 25, 2009 at 1:17 PM, Stefan Kuhn<ste...@eb...> wrote: > > Following up our conference call from yesterday, I want to clarify > > something with respect to the "size" of the applet. This doesn't mean I > > am against making the architecture better or so, I just want to make you > > aware of what we can achieve or not. > > So currently the applet classes are put in a number of jar files. > > What are the sizes of these current jars, and what is the content of > the current core jar? 412 kb. editor.jar is 65 kb. It might have changed a bit, since I did not redo the partitioning with every development release, but that should not half or double the size. If you want to see the content, build/download the application and have a look. > > > Only those are loaded, which contain classes needed. > > How do you test how many jars are loaded when firing up the applet? > And how many on normal use? I only put core, editor and editor-opts.jar in a directory and make sure the applet shows up with this directory pointed to in the html. I also checked the java cache when having the full set, but I did this on windows only, since I couldn't find it on linux. > > This matter, because I see no difference between downloading 1MB of a > single .jar, or 1MB of downloading a set of smaller jars. It is the point with the whole concept that only the mentioned jars are loaded at startup. If all jars would be downloaded, it would be useless, yes. > > So, the question is, how much is currently being downloaded for a the > simplest use case Chris is after? As I said, drawing can be done with only using the mentioned jars. > > > All jars together will contain > > everything (we could in theory leave out classes never used, but it is > > hard to find out which are really never used and there is no problem with > > having unused stuff since it will not be loaded). > > This can be done by defining clear dependencies. But why do things which serve no purpose? If it can be done, ok, but I see no pressing need for it. > > > There are two jars containing the > > core stuff: One called core.jar, which contains averything needed for the > > viewer to show up a mol file > > MDL molfile. What content of it is shown then? MDL molfiles can > contain a lot of content, and certainly more beyond a simple use > scenario... I am using the big.mol in the jchempaint/applettests directory. If the file needs more stuff to display, more jars will be loaded. We could leave the mdl loading out, but I found it is commonly used for display. > > > and one called editor.jar, which contains > > everything needed in addition to this to load the editor, draw a ring and > > a bond and delete the bond. > > If this is the use case, the applet likely be a lot smaller than now. > State of the art drawing applets doing the above functionality are > less than 40kB, even open sources ones. If we want to be competitive, > this has to be our goal. And surely this will be difficult, and surely > this will require further CDK clean up. I think we cannot do this given the applet is a cdk thing. Something like 40 kb is only possible with a purpose written application, I believe. But I may be wrong. See my final remark. > > > When I was talking about "applet size", I meant the > > size of these files. Talking about the size of all files is pointless, > > since they contain everything anyway (the last realese was missing > > something, therefore size was different from jcp application, but this > > was a fault). > > See above. I don't care about the size of all JCP .jars either, only > about those that are loaded in the simplest scenario. Hence my > question, what subset of jars are now loaded in the simple drawing > scenario Chris is after? See above. > > > More specifically, this means reaction stuff will not be in the "core" > > applet and also the isotope factory will not, if not needed for basic > > stuff. So by restricting functionality, _we will not gain anything with > > respect to size (ie size of core jars)_. By refactoring the hub, only the > > reduction of the hub class itselfs will count. > > I don't care of the IsotopeFactory is in the first jar loaded, or in > the third or fifth. I don't want it to be loaded at all. As I said and as it clear from the concept, this is of relevance. If the isotopeFactory is used somewhere, it will be loaded at some point. If it is never used, it will never be used, although it is part of some jar (we could make an unused.jar). > > > As I said I do not want to discourage anybody from doing something, but > > be aware of the concept. > > The above concept uses indices distributed with the first .jar so that > your Java browser plugin knows what additional plugins to download > later. > > What this concept does not address, is define what is the smallest set > of CDK classes we need for a simple drawing scenario applet > functionality. Well, it does, since the contents of the core jars are the minimal set. For me, this "small applet thing" sounds like a major exercise. I wuold suggest we proceed as following: - Fix bugs (this currently in sf and newly found ones) - Implement a reasonable set of new features - Make sure it is stable (this is a major problem with the applets, Angel and Marcus reported problems which need to be addressed) - Do the partitioning, make sure the minimal set works, further split up the residue jar, which is a bit big right now etc. - Then make a release, which might be 2.6 or 3.0, I don't care I believe if we want to have the application in use, we need to do maintainance releases regularly. If we now stop till the grand design is finished, it will mean the next release is away years. We cannot seriously expect people to use such an application, I believe. Since a small applet might be good as well, we could also do a maintainance branch and a small-applet branch. I would favor this given the current situation. Stefan -- Stefan Kuhn B. Sc. M. A. Software Engineer in the Chemoinformatics and Metabolism Team European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2657 Fax +44 (0)1223 494 468 |