This post is _very_ interesting. It clarifies the distinction between plugins and extensions. In my mind they were the same, and I was always wondering why there existed the two of them.
Now you say plugins are present in the basic package while extensions are third-party... In my mind I imagined something more like Linux, with OJ Core beeing like the Kernel and OJ versions like distributions, made assembling the Core with any sensible combination of plugins. So I can't see any distinction between a basic package and any other distribution, but now I see other people see this distinction. For many of the point you listed, you wrote: "It can be extracted like a plugin?: Is possible. Any case there would be lot of dependency with it." What dependencies are you meaning here??? On other plugins or on third party libraries??? For other listed points , you wrote: "It can be extracted like a plugin?: Difficult" Here I have to trust you, because I obviously don't know your code, but I suspect that it may indeed be difficult because the Core make it so. Many functionalities may be difficult to implement as plugins because the Core has no support for them to be pluggable. But if it had, it should be easy to do. So the question is: "...is it worth the effort to make to Core support more pluggability???", and: "...is anyone available do that???". If the answer to any of these question is "no", then functionalities will go inside the Core. I'm _very_ happy reading that you are trying to develop not only a desktop solution but a system also usable as a server, mobile, etc. This is _great_!!! I always thought that it's the only reasonable way it should be. And also in this respect I see a smaller Core as an advantage on the way to creating such a modular platform. Reading your post it seems you are developing an impressive amount of useful functionalities, that should have be present in OJ. Also you are 9 people working full-time, and this is, I believe, the strongest task-force in the OJ arena. Putting all together it's quite tempting to say: "...why don't we simply adopt the Core from Kosmo as the OJ Core altogether...?!?". In the end I want to thank you very much for all your work!!! I didn't test Kosmo yet, but now I'll go download and give it a try!!! Bye Paolo Rizzi > -----Messaggio originale----- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] conto di > [EMAIL PROTECTED] > Inviato: mercoledì 28 febbraio 2007 17.47 > A: jump-pilot-devel@lists.sourceforge.net > Oggetto: Re: [JPP-Devel] Suggested Procedures For > CollaborativeDevelopment Of OpenJUMP > > > Hello all: > In first place I would like to say hello everybody. This is > the first > time I write directly to the list and we (at Kosmo team) are very > happy with it. > Lot of very interesting ideas and proposal are being write > here during > the last days. I would like to explain some of my point of > view about > some of them. > > CORE: > A big part of the mails are about core matter. As Larry said, some > days ago, I feel kind of guilty about have heated up the > issue of JUMP > flavor proliferation. Stefan wrote: > "I have not read fully all the email/blog entrie...but i saw a quite > impressive list of changes on Kosmo and i wonder if all this changes > are not to much/necessary." > Our fault, we should explain that list better. As Landon > suggested we > are agree a "core changes log" in each of the "brands" is > important to > do, as first step to know which changes to promote. > In the last mail Sunburned ask Larry for: > ?[1] Provide me with a "Java Package Map" for Kosmo that I > can post on > the wiki. > [2] Send me a brief e-mail when new classes/interfaces are > added to an > official release of Kosmo, or when existing classes/interfaces are > modified in Kosmo. > [3] Select 2 or 3 of the improvements to Kosmo that you would > like to > see in OpenJUMP.? > You can ask us also, we will try to answer you as best as we > can. We > are now making a detailed "Java Package Map" but it is still not > finished. We have some ?urgencies? during last weeks and we > don't want > to delay more time v:1rc1. Any case I´ll try now to explain a little > more in detail some of the changes: > --- > 1 >Different rendering procedures for each data origin: > Optimized/different for image/point/line/polygon layers. > Why: Main reason, we need to work with a very extensive data. > Very big > layers with complex symbology. At the same time we need not to > slowdown render speed, we had to optimize it for each data > origin. So > it was impossible to do it with the initial core. > Yesterday Stefan said: ?I actually wondered what is the advance of > heaving separate renderer for points, lines and polygons???. Can > somebody explain this?? > I will try to explain what we mean with this sentence (a little bit > confuse perhaps): > Renderer, different ones for: > - Image data > - Shp > - Data base > - Memory layers (except image layers) > Optimizations: > - Lines and Polygons: If we want to draw something that in actual > scale is just a pixel we draw it directly. No other time consuming > process is done. No border, no fill, just a colored pixel is sent to > screen. > - When we read a layer to render we just take in account meaningful > attributes. We use what we call ?geometric iterator?. If the > layer has > twenty data fields but we have to use only one to generate > the symbol > we don't read the other ones. (SHP and Data Base memory layers are > different, in that cases all the data was read beforehand). > - In the SHP case we draw directly (no JTS before drawing). > - Obviously if complex SLD is used rendering process becomes slower. > David said about rendering speed: ?Some explanation may have to do > with the rendering technology used: Jump uses Java 2D while Geotools > (kosmos / udig) use direct draw (if I recall correctly).? > Sunburned wrote: ?Does this mean that Kosmo implemented there own > rendering logic? I think that is the path that UDig took, and > I think > it would be a real pain-in-the-neck to duplicate. Not to mention the > fact that using the Java 2D API makes it easier for programmers to > tool around with OpenJUMP's rendering system because they don't have > to learn a bunch of custom code. We should also have an easier time > reaping the benefits of improvements to Java 2D in the future.? > It is not correct. We use Java 2D, we don´t use Direct Draw. > It can be extracted like a plugin?: Difficult. > --- > 2 >Different data access for each different origin: Different > spatial > index for each type (shapefile layers, memory layers, database > layers...). > Why: Same reason. We need to have a progressive data access > for it. We > use on demand access. > It can be extracted like a plugin?: Is possible. Any case > there would > be lot of dependency with it. > --- > 3 >New database on demand access, full read/write access: > PostgreSQL/GIS, MySQL, Oracle Spatial/Locator. > 4 >New optimized full read/write numeric data tables access: .dbf, > .mdb, .csv, PostgreSQL, MySQL, Oracle. > 5 >Optimized image access: ecw, mrsid, jpg, bmp... with > transparent to > user catalog creation from images in a specific directory. Advanced > WMS interface also. > Why: Self explained. We need this functions. > It can be extracted like a plugin?: Is possible. Any case > there would > be lot of dependency with it. > --- > 7 >Very advanced and professional SLD OGC symbology: With > numeric and > geometric filters, rules, metadata, etc. > Why: For some of our works it was necessary more flexible and > powerful > symbol engine. > It can be extracted like a plugin?: Difficult. There are > renderer relations. > --- > 9 >Full projection view/data support: You can change > projections on the fly. > Why: For some of our works it was necessary. We have data with very > different origins. > It can be extracted like a plugin?: Difficult. There are > renderer relations. > --- > 11 >New Layer-Layer, Layer-Table and Table-Table managing > environment: > This let us to incorporate a very complex client database > model inside > Kosmo, navigate across and use it. > Why: Usability is one of our goals and is very important for our > users. What people tell to us is that they don't want to have > to deal > with other (somehow complex for them, basic users) database > (Postgres > or MySql) to create relations and symbolize with them. > It can be extracted like a plugin?: Difficult. > --- > 15 >New project managing interface: Views, tables, layouts, > relations, > hyperlinks,... > Why: We like this way of GIS structure. We and most of our potential > users are used to it. > It can be extracted like a plugin?: Difficult. > --- > 6 >Advanced printing module: Able to print at different resolution > heavy image and vector layers. Utility for automatic cartographic > serial printing. Full image and vector printing. > 8 >Advanced query builder: With numeric and geometric filters too, > rules, metadata, etc. > 10 >New hyperlink managing environment: 1:1, 1:n supported. > 12 >New geoproccesing tools: (Just like an extension). > 13 >New CAD editing tools. > 14 > Dxf read/write. (We are finishing so it will be not in > v: 1.0rc1 > but probably in next one). We are changing both read and write > process. (Actual contract functions necessities) > 16 >New advanced topology quality control rules: On line or > batch processing. > 17 >New scientific field calculator. > 18 >New advanced numeric field editing: With field data domain, for > complex database models and error decreasing in data introduction. > Why: Self explained. We need this functions. > It can be extracted like a plugin?: Yes, some of them actually are. > --- > So, in the list there are specific core functions, functions that > could be extracted and functions "easy" to extract. > We are trying (when is possible, mainly in the new tools we make) to > have different packages so, if we need to, it will be easy to make > plugins or extensions from them. In fact one of the Kosmo important > possibilities is "extension" management. > > PLUGINS > To be sure terminology is the same we understand that: > * Core is the ?heart?. > * Plugins are distributed with the basic ?brand package?. > * Extensions are plugins that not belong to the basic package that > should be ?brand? interchangeable. We work for diverse clients. All > the functionalities cannot be located in the nucleus of the > platform. > There are clients who require some type of confidentiality in their > procedures of work, in their know-how. For that reason the > possibility > of making extensions is very important. That way we can give them to > the client and he will be the one who decided if publishes > them or not. > For us it is important that if a extension has a dependency > problem to > load (plugins will have not as they belong to the basic > ?package?) it > must be not crash the application. At the moment we did not > implement > any dependency engine. Any case extensions are important to us (in > fact we have an extension manager) so we thought about implement it. > Sunburned ?Plan A? sound to us simple but effective. If > something can > be simple much better. There some aspect to think about (as Paolo > said) but we think it is a good start. > > INTERNACIONALIZACION > We use OpenJump engine. There are almost no changes. Main addition > perhaps is that when a chain is not found we just add a > generic label > instead. This way system still work. This event goes to the log file. > (A log file is created and maintained instead of Java Dos Windows. > This way is easy to debug. v:0.8.3 has by the moment more than 2300 > downloads and is easier ask for log file in the case of > errors happen). > > TEAM > There are an Stefan mention about it: > ?btw: if we would have a team of 5 developer..? dont know how far we > could be. Actually i guess on Jump were working only 3 people?? > We think this point is very important. If you want to arrive at some > higher point you need the idea, the resources and the people. > When we decided to create Kosmo we saw it not only like a desktop > client. Kosmo would be a complete platform: A data catalog, Web > server, Web Client, Desktop Client and Mobile platform (In > next months > there will be news about them). So Kosmo-Desktop is only one of the > parts of our project. This is the reason why there are as Larry said > so many Java Files. (Version 1rc1 will have more than a > hundred more). > In any case is very important for us that all the new > functionalities > relative to the platform will be integrated of coherent form > with the > idea of general platform of which we have spoken. > This is the reason why we are actually 9 developer at Kosmo team all > of us engineers or programmers of superior degree dedicated 100% to > this activity. Our members left the jobs in which they were (some of > them very well remunerated and stable) and they were dedicated > completely to Kosmo development (most of AGILE member are in SAIG > actually).The SAIG personnel lives on its work in the company. > This was the only way we found to make the enterprise start to work. > The speed of development of Kosmo and the priorities come > given by the > nature from SAIG. Logically if we have to finish a project within a > month the necessities of this project are the first to cover. Like > everyone that works in a company knows, the priorities can > change from > a day to another one. We have to be flexible and fast. > Sunburned wrote: ?I don't think there is any doubt these guys are > doing a lot of work with OpenJUMP, but we should remember that > quantity doesn't always mean quality. I should have mentioned > this on > my previous message.? > Of course. Imagine for us. If we have not enough quality our clients > will not want us and next end of month could be a trouble. We > know we > must be better, we are triying. > > Regards, > Manuel > > > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the > chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge &CID=DEVDEV _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
