Re: Scripting in Gnome

> Which Python/Perl/TCL/Ruby/etc all excel at.  Again, we have the script
> side of the solution solved.  It's pointless to waste time reinventing
> that wheel.
Yes but at a price because integrated scripting would therefore depend
on every possible interpreter being installed on your system.

> > 
> > 
> > > And maintainability suffers because of it.  Code in HTML just sucks
> > > IMHO.  Code should reside separately with the XML only being a
> > > template.  Model/View rocks.
> > You can do that anyhow in XML using include files - one for
> > interface/one for code
> But what do we actually need the XML for?  You've repeatedly stated how
> we need XML to solve this problem without actually stating why.  XML is
> just a syntax for heirarchial data.  What does that have to do with
> connecting a script language VM/interpreter to an application?

XML is just a good way to define the syntax for a particular script
language in a generic script engine. It could be done using an ini file
but XML is more standard nowadays.

> > No the XML will make use of Bonobo/Orbit not replace it. Again Im
> > talking about mini scripts here - its nothing that competes with Perl or
> > Python. All it is is a generic script engine which enables scripts to be
> > used in any language whoose syntax is defined using an xml definition. 
> Um, for what purpose?  what do you need this fictional languages for
> that you acn't already do with real life languages that already have
> perfectly working Bonobo/ORBit bindings?

Let me give you an example:

Suppose we have a script engine as a bonobo component which is used by
Gnumeric to enable users to write macros. SUppose johnny writes his
macros in Gnumeric using python and chris writes his macros in Ruby.
What happens when chris sends his gnumeric spreadsheet file with
embedded Ruby macros to johnny, who does not have a Ruby interpreter

Of course he cant execute those macros if he does not have the Ruby
interpreter installed. This problem is therefore magnified many times if
you consider what happens with a generic script interface - you would
need every possible interpreter installed on your system to guarantee
you could execute any macro.   

Enter my proposed integrated generic script interface and that problem
goes away. There would be no dependancy on any other libs or
interpreters. Its the same case with Microsoft's activex scripting
control. You get language independance and minial dependancy on other

Remember I am not proposing to replace perl and python - I'm just
proposing an integrated script engine. The languages to be used need not
be more powerful than shell script.

> > 
> > VBA is needed anyhow for things like Gnumeric if they want to achieve
> > compatibility with Excel
> This much is true.  That is a separate problem, however.  That's the
> need for yet another interpreter which would just use the same entrance
> points that Python/Perl/etc. would use in a scripted application.
Yes, but its no more effort than to write a generic script engine.


> > 
> > > 
> > > --
> > > J5
> > 
> > _______________________________________________
> > desktop-devel-list mailing list
> > desktop-devel-list gnome org
> >

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]