Re: Support for callbacks...

[James Michael DuPont <mdupont777 yahoo com>]

--- Lars Clausen <lrclause@cs.uiuc.edu> wrote:
> On Thu, 17 Jul 2003, James Michael DuPont wrote:
> > I have been quite for a long time,
> > most of you remember my bitching and moaning, and lots of vapor
> ware.
> > 
> > There has been little interest in the cross compilation project,
> and
> > that has been put aside. I have been using dia alot for diagramming
> and
> > am very happy with it. 
> > 
> > I think it is possible in this lifetime to create a collaborative
> > environment where we can all build in simple components.
> > 
> > Dia will need to gives up some control over the internal
> representation
> > of the data, or aleast allow for a network access to that
> > representation, then we can make truly impressive application out
> of
> > dia.
> [...]
> > I intend on building this functionality into dia. Basically
> replacing
> > the xml save with a xml-rpc post of the data. Later allowing diffs
> to
> > be sent incrementally. (undos as well). The entire system will
> allow
> > complete scripting extension of dia via any language that is able
> to
> > understand xmlrpc (all can) . 
> [...]
> 
> > Of course all these heavy protocols can be implemented using inline
> > modules that are just linked in via ipc or via static linking...
> but
> > then you lose the flexibility.
> 
> It's an interesting direction.  I guess it could be good for a
> Wiki-like
> system for diagrams.  However, I still think most diagrams will be
> made
> with a stand-alone local Dia, so it'd be important that the non-RPC
> version
> (equivalent to the current Dia) should not suffer in efficiency.
> 
> However, I don't think this is the right time for such an
> all-encompassing
> change to Dia.  We're getting closer to having something that is a
> viable
> tool for individual use.  I'll try to steer towards a version 1.0
> that has
> as few incomplete pieces as possible and is internally consistent.  A
> number of interface issues need to be worked out, as well as some
> structural things that are essential (multi-object properties, for
> instance).  Until this is done, tearing into the basis of Dia to do
> collaborative versions is just going to be counter-productive.
> 
> I'm not sure what change would be necessary to make xml-rpc save, as
> you
> suggest.  It'd be interesting to have a prototype collaborative Dia
> that
> just sends diagrams back and forth, probably using a plugin to talk
> to each
> other.  But I'm not going to start major changes now.  We've made so
> much
> progress that I don't want to risk it on a new fancy thing before we
> have a
> stable branch.
> 
> > 
> > I think people would use this function of dia, and it would allow
> you
> > to make interactive web applications using dia as browser....
> 
> That's a lofty goal.  And not one that I see as particularly relevant
> to
> Dia.  Dia is meant to support in making diagrams of various kinds,
> not
> become an interactive web application basis.
> 
> I'm sorry if I come off as harsh, but I believe it's important to
> keep the
> focus on what we're trying to create.  There are many, many things
> that can
> be done usefully with Dia without turning it into a browser. 
> Collaboration
> is interesting, and I'd like to see plugins with that intent.  Just
> don't
> expect major changes to support it, as I'm (slowly) gearing towards a
> 1.0
> release.


Lars, I completely respect your skepsis, and to be honest, i would be
skeptical too. 

My only wish is to be able to easily add in plug-ins with many
languages. This will be possible as just a save filter as well. The
idea  of allowing a "normal" plug that can also route to the internet
would meet both of these goals.

Basically what I would like to help here with is making a  clean object
model for scripting dia, and on the basis of that create a very
abstract API that can be used for network based and non-network based
applications.

The entire reason for adding in networking is to make dia more usable, 
that can be done with also just adding code to dia itself. I think
however that dia is an important part of a whole, by working out an
abstract api, then we can make loosly coupled tools that are very
powerful.

What do you think is the best starting place for such an abstract api
into dia?

mike



=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com