I want to respond in more detail to you and Paolo. Let me just say this for now:
- I'm not talking about rewriting every class in the core. That would definitely be a major feat. I will likely only touch the code that I interact with as part of my integration of the docking window framework. - My change to support low-RAM architecture will only be to the interface of the FeatureCollection. I'm not talking about providing an implementation that caches features on disk. Not yet. I do have some existing FeatureCache code that I worked on while I was sick with the flu, but I'll keep that separate for now. It needs to be modified anyways, as I set it up to work with the existing architecture by using FeatureFacade objects (proxies) to keep a lightweight Feature implementation in memory. If I make the change to the FeatureCollection interface that will no longer be necessary, and it will greatly simplify the FeatureCache code. I realize my greatess weakness is trying to do too much, and never getting even a little bit done. So I'm going to look at the list on my blog post and see where I can scale the refactoring back. I've decided I won't add any new features during the refactoring except for the docking windows framework, the other stuff can wait. If I don't tell myself no, the refactoring will never get done. I really hope the refactoring will make OJ a viable platform for a few more years into the future. I think future refactorings like this will be needed as the Java language and the underlying computer technology changes. I believe we must continue to refine the architecture of OJ to keep up with these changes or the program will slowly die. Perhaps I am wrong about this. There may be a lot of really old programs that are still being used by a loyal user base. SS On Thu, Dec 11, 2008 at 3:19 PM, Michael Michaud <michael.mich...@free.fr> wrote: > Hi Landon, > > Every suggestion you make in your blogspot makes sense to me. > They are not easy tasks and I'm not particularly optimistic about our > ability to achieve only one of them, but let's say that tomorrow, we get > ten new contributors, ready to spend as much effort as you do on the > project :-) > > docking framework : I just know that developpers from jEdit project have > improved their previous docking architecture which now support several > docking framework through plugin implementations (a plugin for MyDoggy > has been developped, others can be added). I give you the link, I'm not > able to comment it > http://jedit.wiki.sourceforge.net/Docking+framework?f=print > > Extraction of OpenJUMP RCP code, extraction of OJ's model, improve the > separation of model and view : each proposition seems good to me. > Some important parts of OJ architecture are already clearly identified > through packages (feature package, model package). I think there are > tools around there to evaluate the dependency between packages inside a > project. What about the division of the plugin collection into > com.vividsolutions plugin and org... plugins ? > > Migrating existing code to java 5 seems a big task. I agree it would > make the code more readable. Some packages are probably better > candidates (again : feature package with attribute types, feature > collection...), but it may be difficult to migrate only a part of the > project. > > Low-ram architecture : I think that creating a reader which doesn't load > every thing in memory is not too difficult (some plugins have already > been done by developpers like A. Zabala from agile/gvsig). What is more > difficult is to read from disk, to manage changes in-memory, and to > commit in-memory changes back to disk (I think saig/kosmo has such a > transactionnal system). > > Thanks to Paolo which added precious comments to your post. > > my 2 cents > > Michaël** > > > > Sunburned Surveyor a écrit : >> Not in the JPP SVN, but in my own fork. :] >> >> If you are interested in what is involved, you can read more on my blog: >> >> http://openjump.blogspot.com/ >> >> If anyone has suggestions on how I can design the architecture so that >> docking window frameworks would be "pluggable", I'd be interested to >> hear them. This would allow me to switch out the docking window >> framework in the future if our core group decides to go a different >> direction. >> >> The Sunburned Surveyor >> >> ------------------------------------------------------------------------------ >> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. >> The future of the web can't happen without you. Join us at MIX09 to help >> pave the way to the Next Web now. Learn more and register at >> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> >> > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
