I've put up a blog post where I propose some restrictions that might guide the changes we will allow to OpenJUMP's Feature Model as we add more funtionality to the program in the future. The restrictions would basically help us to determine if new functionality justifies modification of the Feature Model, or if the new functionality should be implemented by alternative means in a plug-in instead of in the core.
I think this is an important discussion to have, as it will really determine what type of personality the OpenJUMP core will have in the future. Will we allow all types of flexibility but suffer from exterme complexity? Will we be disciplined enough to sacrifice some functionality for the sake of a simple Feature Model? I realize not everyone will agree with my perspective, or on my suggested restrictions. But I thought it might help us generate some discussion. I think Paul Austin's recent posts on a named FeatureSchema are evidence that OpenJUMP programmers would benefit from some decisions in this area. I for one would really like to know if we are going to have a mechanism to uniquely identify Layers, and if not, whether we will uniquely identify FeatureSchema as Paul suggested. You can read my blog post on this subject at the OpenJUMP blog: http://openjump.blogspot.com/ Thanks, The Sunburned Surveyor ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
