Peppe wrote: "Hi, the discussion is going down, probabily we need more time to "digest" the proposal."
I don't think we need more time to digest. We just get busy and things die off. Thanks to Peppe for keeping the conversation alive! Kosmo Programmer wrote: "About plug-in models, both Openjump and Kosmo are quite different, and it is not easy to do it without a very hard job." I'd be really interested in learning about the changes that Kosmo made to OpenJUMP's plug-in model. What changed, and why? I know one thing I hoped to add to OpenJUMP was support for plug-in dependency. Is it possible to learn more about Kosmo's plug-in model and how it is different from the one in OpenJUMP? The ability to share plug-ins via a common plug-in model would be very powerful and I think worth a lot of work. The only reason I can see for avoiding this is if the Kosmo plug-in mechanism brings with it a great deal of complexity. Simple plug-in development is one of the things I like the most about OpenJUMP. Kosmo Developer wrote: "About file formats, projects file, this is more easy. Some about it: -It would be useful for user in order to be able to switch from Kosmo to OpenJump and viceversa. -This could some like "save as..." project. This mean user could switch from one to another software, use the different tools in each case, and go back again. -It would be not possible to "save as.. " the full possible options of each one, due to Openjump save some characteristics in the project file, just like Kosmo do (topologic rules, SLD, layer and tables relations, hiperlinks....)." All of this makes sense. I didn't think about having the ability to export a Kosmo or OpenJUMP project file from each respective program, but it is a good idea. But we shouldn't rule out eventually adopting the same project file format. The first step should be identifying the differences in the two formats. I must admit I am not that familiar with OpenJUMP's project file format, but I can get familiar with it if there is a change to collaborarte with Kosmo. The Sunburned Surveyor On Wed, Mar 19, 2008 at 11:28 AM, listas <[EMAIL PROTECTED]> wrote: > Dear all. > > Sorry for delay. > > We think the way Giuseppe show and SS comment can be good like a medium > term. > This is because it is user driven, and the user could get the benefits. > > About plug-in models, both Openjump and Kosmo are quite different, and > it is not easy to do it without a very hard job. > > About file formats, projects file, this is more easy. Some about it: > > -It would be useful for user in order to be able to switch from Kosmo to > OpenJump and viceversa. > -This could some like "save as..." project. This mean user could switch > from one to another software, use the different tools in each case, and > go back again. > -It would be not possible to "save as.. " the full possible options of > each one, due to Openjump save some characteristics in the project file, > just like Kosmo do (topologic rules, SLD, layer and tables relations, > hiperlinks....). > > What do you think about it? > > > Best regards > Antonio Muñoz > > > > Sunburned Surveyor escribió: > > Peppe has identified two (2) good opportunities for collaboration, aside > > from the aspect of library design that I mentioned earlier. > > > > [1] Common file formats. > > [2] Common plug-in model. > > > > These were excellent ideas by Peppe. (I would point out that if Kosmo and > > OpenJUMP can share file formats, for things like projects, as an example, > > then we can also share libraries for the maniplation of these file formats > > at a lower level.) > > > > Here is a question for Kosmo. How is their project format file different > > from the one currently used in OpenJUMP? How have they changed the plug-in > > framework? > > Having the answers to those questions would put us on a path to some real > > discussion about how to preserve compatibility and cooperation in at least > > these to areas. > > Good work Peppe? > > Any comments? > > > > The Sunburned Surveyor > > > > On Mon, Mar 17, 2008 at 11:55 AM, Giuseppe Aruta > > <[EMAIL PROTECTED]> wrote: > > > >> Dear all, > >> > >> while waiting other opinions, I want to give "my 2 cents" to this > >> discussion. > >> > >> I think there is no need to derfine a "long" term project with the > >> integration of tools from one softwere to the other. > >> > >> If I see the story of Jump and its "sons" and plugins, I image that the > >> main problem is that Jump software suffered loosing of compatibility with > >> the former versions, expecially plugin. > >> > >> This happend with Kosmo and OJ, but this is happening with OJ 1.2 NB if we > >> considerer that, with the new improvements, many plugin do not work > >> (expecially Pirol's ones which represent one of the most specialized OJ > >> "battlefront"). > >> > >> I image that a "short" term common project between Kosmo and OpenJUMP > >> would be to work on a common way to open/save projects. If Kosmo could > >> open OJ project and "viceversa" it will give a great benefits for the > >> user who can switch between the two software and use what they need. This > >> probabily won't effect on any other prblem (comatibility/client driven/etc) > >> > >> Is it practicable? > >> > >> Regards > >> > >> Peppe > >> > >> > >> > >> > >>> Dear Antonio, > >>> > >>> I thank you for your comments. It is always good to > >>> know your (positive) > >>> perspective on such a colaboration. > >>> > >>> stefan > >>> > >>> listas schrieb: > >>> > >>>> Hi all. > >>>> > >>>> First time, many thanks to Peppe, not only for > >>>> > >>> your nice collaboration > >>> > >>>> with Kosmo, but for your interest in find "a > >>>> > >>> common area for the > >>> > >>>> development of both brother" (I really like that > >>>> > >>> definition). > >>> > >>>> I would like to share some ideas/feeling about > >>>> > >>> your comments. > >>> > >>>> As you said, Kosmo is developed by project needs, > >>>> > >>> but maybe it is better > >>> > >>>> to explain a little more the meaningful (our > >>>> > >>> meaningful) of "project > >>> > >>>> needs and project driven development": > >>>> > >>>> Our main objective is not to develop Kosmo itself. > >>>> > >>> Our main objetives > >>> > >>>> are the "client driven projects". To be able of > >>>> > >>> realize correctly those > >>> > >>>> projects, we need continuously build and improve > >>>> > >>> Kosmo. So, about a > >>> > >>>> "strict schedule" (a good subject to analyze), > >>>> > >>> this exist, but mainly > >>> > >>>> for those projects. So, strict schedule for Kosmo > >>>> > >>> exist only for what > >>> > >>>> is neccesary to carry out our commitment with > >>>> > >>> clients. Without clients > >>> > >>>> we could not maintain Kosmo project. We are just > >>>> > >>> a small company who > >>> > >>>> think we are able to work and live in a free > >>>> > >>> software model, and return > >>> > >>>> to community all we can. > >>>> > >>>> About community, Kosmo is not only focused on a > >>>> > >>> spanish user community. > >>> > >>>> In fact, in the last 1.2 versión it has been > >>>> > >>> translated into italian > >>> > >>>> (thanks to Peppe), russian (thanks to Sergey > >>>> > >>> Smirnov), german (thanks to > >>> > >>>> Johannes Sommer), brasilian portuguese (thanks to > >>>> > >>> Territoriolivre.net > >>> > >>>> people), baske (thanks to baske administration > >>>> > >>> people). Some other new > >>> > >>>> languajes are coming soon (czech, slovak...).. We > >>>> > >>> directly maintain > >>> > >>>> both, english and spanish version. > >>>> > >>>> As you said, we have an important developmet team, > >>>> > >>> because we have > >>> > >>>> client driven projects that let us to maintain it. > >>>> > >>> We think other way > >>> > >>>> it is not possible for us to improve and to let > >>>> > >>> Kosmo growing. > >>> > >>>> We have translated/included a lot of code/tools > >>>> > >>> from > >>> > >>>> OpenJUMP/Jump/DeeJump/Pirol/Sigle projects (and > >>>> > >>> other no Jump family > >>> > >>>> utilities). > >>>> > >>>> Like some of you we would have liked a better > >>>> > >>> cooperation. We still > >>> > >>>> would like it. > >>>> > >>>> -Maybe all we (you and us) have been, and will > >>>> > >>> continue very busy to do > >>> > >>>> enough work in draw a common way to work together. > >>>> -Maybe it is not very easy. > >>>> -Maybe we too could do an additional effort and > >>>> > >>> collaborate in help > >>> > >>>> translate and merge OpenJUMP into Kosmo. > >>>> -Maybe would be neccesary strict schedule only for > >>>> > >>> those who need to > >>> > >>>> attend different/external Kosmo project commitment > >>>> > >>> (private commitment), > >>> > >>>> and absolutely free to dedicate the time they > >>>> > >>> want, when they want for > >>> > >>>> people developing Kosmo itself. In other words, > >>>> > >>> none strict schedule > >>> > >>>> for Kosmo itself. > >>>> > >>>> About Intevation/LatLon and SkyJUMP team, we think > >>>> > >>> it would be a very > >>> > >>>> good opportunity to get a positive synergy between > >>>> > >>> us. > >>> > >>>> We are not sure how easy/difficult arrive to this > >>>> > >>> objective could be. > >>> > >>>> If we are able to arrive, there will be a new star > >>>> > >>> in the GIS world. We > >>> > >>>> are sure walking the road in this way could be > >>>> > >>> very exciting. > >>> > >>>> Best regards > >>>> Antonio Muñoz > >>>> > >>>> > >>>> Sunburned Surveyor escribió: > >>>> > >>>>> I must agree with many of the points made by > >>>>> > >>> Stefan and Michael. I > >>> > >>>>> know the language would be a barrier for me. :] > >>>>> > >>>>> I think someone (I can't remember who) looked at > >>>>> > >>> this issue rather > >>> > >>>>> closely and decided that it would be a huge > >>>>> > >>> amount of work to > >>> > >>>>> integrate the Kosmo changes into OpenJUMP. > >>>>> > >>>>> Having said that, I'm always looking for > >>>>> > >>> opportunities to share code > >>> > >>>>> with GeoTools, Deegree, Kosmo and others. Paul's > >>>>> > >>> work on the > >>> > >>>>> DataObjects framework should help with that, as > >>>>> > >>> it will allow us to > >>> > >>>>> overcome some of the challenges presented by the > >>>>> > >>> different feature > >>> > >>>>> models. > >>>>> > >>>>> I don't know that we need to "merge" Kosmo and > >>>>> > >>> OpenJUMP. What would > >>> > >>>>> really benefit everyone is if Kosmo and OpenJUMP > >>>>> > >>> programmers could > >>> > >>>>> develop libraries that could be shared between > >>>>> > >>> programs. We can do > >>> > >>>>> this by splitting out the lower level compontents > >>>>> > >>> that could then be > >>> > >>>>> used by different programs. Take, as an example, > >>>>> > >>> Java code that would > >>> > >>>>> work with TINs. You could separate the code for > >>>>> > >>> TIN model I/O and > >>> > >>>>> manipulation into a separate API that could be > >>>>> > >>> used by different > >>> > >>>>> programs, and then build a separate > >>>>> > >>> program-specific plug-in/user > >>> > >>>>> interface for Kosmo, UDig, and OpenJUMP. > >>>>> > >>>>> I think the only obstacle to this type of thing > >>>>> > >>> is better > >>> > >>>>> communications between projects. I'd love to hear > >>>>> > >>> suggestions on how > >>> > >>>>> that can be improved. I'm already subscribed to > >>>>> > >>> the UDig, Deegree, and > >>> > >>>>> GeoTools mailing lists. > >>>>> > >>>>> Maybe each project could appoint a volunteer to > >>>>> > >>> coordinate new > >>> > >>>>> functionality being incorporated into each > >>>>> > >>> project. Or maybe we try > >>> > >>>>> and host a quarterly online meeting to discuss > >>>>> > >>> opportunities for > >>> > >>>>> collaboration? > >>>>> > >>>>> I think we could accomplish a lot by changing our > >>>>> > >>> library design to > >>> > >>>>> share low-level components. > >>>>> > >>>>> The Sunburned Surveyor > >>>>> > >>>>> On Sat, Mar 15, 2008 at 1:26 PM, Michaël Michaud > >>>>> <[EMAIL PROTECTED]> wrote: > >>>>> > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Kosmo benefits an important developper team, and > >>>>>> > >>> I would have liked a > >>> > >>>>>> better cooperation between OpenJUMP and Kosmo. > >>>>>> I think the main problem is that kosmo started > >>>>>> > >>> its development from an > >>> > >>>>>> old version of Jump, and when the first > >>>>>> > >>> opensource version of kosmo was > >>> > >>>>>> published, jump and openjump had already made > >>>>>> > >>> good progresses. > >>> > >>>>>> Now, it would be a lot of work to merge all > >>>>>> > >>> openJUMP improvments into > >>> > >>>>>> kosmo (or the opposite). > >>>>>> I think OpenJUMP lacks development power to > >>>>>> > >>> proceed to a big change like > >>> > >>>>>> integrating all kosmo's improvements or merging > >>>>>> > >>> openjump goodies into > >>> > >>>>>> kosmo's core. > >>>>>> The way kosmo is driven maybe another > >>>>>> > >>> difficulty (highlighted by > >>> > >>>>>> Stefan), and language and code comments may be > >>>>>> > >>> another difficulty (I did > >>> > >>>>>> not check how kosmo code is documented). > >>>>>> Other comments from OJ's active developpers ? > >>>>>> > >>>>>> my 2 cents > >>>>>> > >>>>>> > >> === message truncated === > >> > >> > >> > >> Inviato da Yahoo! Mail. > >> Il servizio di posta con lo spazio illimitato. > >> http://it.docs.yahoo.com/mail/overview/index.html > >> > >> > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2008. > >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> _______________________________________________ > >> Jump-pilot-devel mailing list > >> Jump-pilot-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > >> > >> > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
