--- Lars Clausen <[EMAIL PROTECTED]> wrote: > On Thu, 16 Jan 2003, James Michael DuPont wrote: > > > > --- Hans Breuer <[EMAIL PROTECTED]> wrote: > > > >> >If there's also a perl plugin coming up, we'll > >> >need to encapsulate these things differently, so they behave the > >> same > >> >between main program and plugins. > >> > > >> There is nothing which can be done in Perl which can not be done > >> in Python but readable. Not to start language wars but do we > >> really need another language binding if we lack resources to > >> maintain one? > > > > yes we lack resources, but not will power. > > > >> > >> So many people with bright ideas, so many vapor ware ... > > > > Yes hans, almost all of my ideas about DIA are vapor right now. > > > > This is directly related to the work I have been putting into the > gcc > > interface. We have just released a version for testing > > http://freshmeat.net/projects/introspector/ > > > > The issue of bindings is difficult, but in the end after some > > discussion, I have come up with the following idea, please comment. > > > > 1. OAF/Bonobo : this is a fat API that supports costs more than we > need > > for scripting and interprocess communication. > > > > 2. GObject2 / GTK : this is the interface we need to script, and > > we can base those scripting interfaces on a standard. For example > the > > GTK2 has a set of perl bindings in the works > > http://sourceforge.net/projects/gtk2-perl/ > > > > I think that the best way forward is to define a new API for dia, > > and then start factoring the code from the app back underneath it. > > > > Here are the classes that i would like to see : > > > > 1. application > > 2. diagram > > 3. element > > 4. connection > > [...] > > what do you think? > > I think you should look a little more at the current Dia structure. > While > it bears some resemblance to what you describe above, it's different > enough > that it would be an unnecessary pain to change it. I really don't > see the > need to change the Dia API like that.
Well, I will review the differences, as far as I can tell, does the current API does have a clean separation between the implementation and the inteface? Plus I would like to have a clean model for scripting. It will be easier to aggree on a simple new model, and modify existing code to work with it than to try and upgrade the existing. > > I have no idea what the redland/raptor api is. > redland is a rdf application framework : http://www.redland.opensource.ac.uk/ here is the readme http://www.redland.opensource.ac.uk/docs/README.html ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
