[Clipart] KDE and OCAL

[Bryce Harrington]

On Wed, Apr 20, 2005 at 09:02:46AM -0700, Jon Phillips wrote:
> On Mon, 2005-04-18 at 23:54 -0700, Bryce Harrington wrote:
> > On Sat, Apr 16, 2005 at 10:59:34PM +0200, Tobias Jakobs wrote:
> > > Am Freitag, den 15.04.2005, 16:15 -0700 schrieb Aaron Seigo:
> > > > looking at your roadmap, it seems that some of these things will become (more) 
> > > > feasable with the realization of milestones 13 and 17, but i find it's 
> > > > usually good to start figuring out the details sooner rather than later.
> > > > 
> > > Unfortunately the DMS ist paused at the moment, until the Inkscape gtkmm
> > > stuff, he is working on, done. If you have a good PHP/Perl guru he would
> > > be very welcome.
> > 
> > Unfortunately, the gtkmm stuff is looking like it will not end soon.
> > I'm going to try to balance time between the two projects, though.
> 
> Yeah, its taking much longer...but that is an Inkscape issue... ;) I'll
> see how I can help on both...

Great, thanks.  I did some work for dms last weekend, and will this next
weekend to work too.  Haven't decided if it'll be dms or gtkmm.  Guess
whichever strikes my fancy when I wake up.  ;-)

Btw, I've also been thinking over the distribution scheme a bit more.
Kees and I mulled it over after work the other day and came up with an
approach using rsync that'll probably serve pretty well, and that will
fit in with the existing tarball approach and later can leverage dms.

> > In particular, what we need right now is to redo all of the dms calls to
> > be non-object oriented.  In other words, instead of implementing the API
> > as members of a class, to make them stand-alone functions that accept
> > the owning object as the first argument.
> > 
> > The reason we need this is because PHP does not correctly interpret
> > Perl's object model, and thus object oriented calls don't work.
> > 
> > Anyway, the fix should be pretty straightforward.  It's just a bit
> > frustrating that it has to be rigged up this way.  ;-)
> 
> Could we develop the object model to fit PHP?

Well, ideally yeah we'd just hack into the guts of Perl and PHP and make
them interoperate better, but the Perl guts scare the bejesus out of me,
and I'm guessing PHP guts are about the same.  ;-)

> Or, I guess we could use perl on pages as well, but that would be
> possibly too big of a performance hit.

Hmm, that's an idea...  Can PHP run shell scripts?  If so then it might
be really trivial to solve this - we just create some short perl scripts
that communicate with the server and then return formatted HTML
snippets, that PHP could then insert into the appropriate places in the
page.  Seems a bit of a hack, but a lot less work than reimplementing
vast portions of the system.

> Or, we could re-develop DMS in object oriented PHP.

Well, the problem here would be that then it'd become a web-only app...

The nice thing about the current design is that since it presents a
programmable API instead of a web interface, you can communicate with it
directly through shell scripts, GUI clients, and so forth.  I think this
will be handy because it will enable tools like Inkscape to be able to
save-to-OCAL, and enable prolific artists to upload or update vast
batches of SVG's in one go, without having to upload each one
individually through a web form.

Bryce