Re: Scripting in Gnome

On Thu, 2004-02-05 at 20:09, John (J5) Palmieri wrote:
> On Thu, 2004-02-05 at 12:24, jamie wrote:
> > > That is a ridiculous claim.  That's how slow/bloated software gets
> > > written.  Instead of saying, "KDE doesn't liek Corba," try showing some
> > > benchmarks to prove your claims.  If we're just going off what KDE does,
> > > we have a lot more changes to make to GNOME than what IPC mechanism we
> > > use...
> > 
> > Bonobo is not as popular as COM is on MS platforms - I wonder why that
> > is? 
> Oh come on.  What is this supposed to accomplish?

I was making the point the bonobo is not used as much as it should be
and therefore I suspect there are problems with its current incarnation
using corba.

> > Also Orbit2 admits its around 20% slower than orbit1 in its own
> > benchmarks.
> Have you used any of them?  Please point to these benchmarks
Orbit2 home page mentions performance

> .  A
> scripting interface doesn't need to be fast so I don't know why you are
> using this argument.

True but I want bonobo to be used all over the place and that would make
scripting easier and better. Developers will only use bonobo if its fast
and efficient
> > > This is my point exactly.  What does "consistency" have to do with XML? 
> > > What does Microsoft's supposed-XML file format have to do with anything
> > > regarding IDL?  You don't even seem to understand what XML means.
> > 
> > XML should be used for data exchange which is primarily ASCII for almost
> > everything. There may be exceptions where its more prudent not to use
> > XML. IMO Gnome enfores its HIG for UI consistency and it should do the
> > equivalent for data formats.
> Scripting interfaces is not data exchange.  Its like you read PR
> material and try to make arguments based on them instead of indepth
> technical experience.

IDL is raw data - I dont see any programming logic in it.

> > > 
> > > > 
> > > > >   Using XML would require you
> > > > > to write a new document type for IDL-ish purposes, implement tools to
> > > > > duplicate what IDL already does, etc.  That time you'll waste for no
> > > > > reason, both your time and the time of the programmers who have to learn
> > > > > this new XML document type and tools.  XML isn't necessarily a bad tool
> > > > > for the job (I use it for precisely this purpose in AweMUD), but it just
> > > > > isn't as appropriate as the tool GNOME already has.
> > > > 
> > > > There would be little difference between the two in terms of layout only
> > > > you could make use of XSLT with the XML version.
> > > 
> > > XSLT isn't something you want to subject on people.  Trust me.  And
> > > again, why do you want to waste time reimplementing something we
> > > *already have* in a perfectly usable state?
> > 
> > Change is inevitable - except from a vending machine :)
> Changes happens because it needs to happen not because it is
> inevitable.  Why do you think we have stable API's? 
I was joking hence the :)

> > I am not advocating change for changes sake - Gnome is supposed to
> > support a dozen different languages yet only a handful can use bonobo.
> Have you checked out  Most of
> those support Bonobo or at least Corba.

Yes but what happens if the back end of bonobo changes so that new
bindings need to be done from scratch again (remember I am only
proposing the xml format if bonobo changes)

> > It would be easier to use XML to generate the language bindings for the
> > many languages which dont yet support orbit/corba as opposed to
> > devloping bindings for orbit and  writing IDL converters for each of
> > them.
> But now you are just talking about bindings and we have a process for
> that.  It works well.  It is a reason so many languages support Gnome. 
> Language bindings isn't the problem.   Getting applications to export a
> Corba interface is where the focus should be. 

Getting them to support bonobo yes

> > > 
> > > > 
> > > > > 
> > > > > Unless there is a very specific reason to duplicate/reimplement that
> > > > > work, quit worrying about whether it's XML or not and just use what we
> > > > > already have, what programmers are already familiar with, and what has
> > > > > been designed specifically for the task at hand.
> > > > 
> > > > Again I beleive consistency to be a good thing and worth a little extra
> > > > work. If its a huge amount of work okay fair enough but lets see if it
> > > > is first.
> > > 
> > > Consistency with *what*?  Making a new XML document type and tossing
> > > away existing IDL is the *complete opposite* of consistency!!
> > 
> > thats like saying a UI element that violates your HIG should not be
> > corrected.
> Your logic confuses me.  You make huge leaps.  What does the HIG have to
> do about anything here?  
Nothing, I was comparing the consistency Gnome has in its UI and the
lack of it elsewhere and making the point that it would be nice if there
could be consistency throughout.

> What is incorrect about the IDL?
nothing if you use it just for Corba. If bonobo is decoupled from Corba
is it unreasonable to consider an alternative to IDL?

>   Since when
> was XML made "the Gnome Standard"?  I have said it before but the IDL is
> a standard.  It is consistent.  There are paper equivalent to the HIG
> which describes how to use IDL to export interfaces.   

I don't doubt that.

> <sarcasm>
> While we are at it why don't we translate all our C code to XML so we
> can be more consistent with the HIG and just use XSLT to compile it down
> to assembler?
> </sarcasm> 

I said XML for data (not programming logic)

> I'm not trying to make fun of your ideas, as a concept they have some
> merit, but your arguments so general and based on "buzz" that we seem to
> be going in circles.  Even when people give you legitimate well thought
> out reasons of something will not work, you come back with what is
> equivalent to "but <enter technology of the day here> is good".  Please
> read about the technologies in question and formulate a more specific
> action plan.  Give examples of what the XML format would look like, how
> it would be used and how it would bring advantages over the IDL
> approach.  Answer questions with specifics if you want to get people on
> board to your way of thinking.  I for one am still confused on what the
> XML would have to do with anything and right now it just looks the same
> as the IDL to me.

It would be very similar of course - theres no point making it radically

Suppose I have a scripting interface and I would like to retrieve the
IDL for an object at runtime. Now I could use query_ref but I might want
the actual IDL to build an object wrapper for it at runtime.

If that object returned a chunk of xml that would be okay. If on the
other hand I got back raw IDL it would be a pain -  I reiterate its
easier to parse xml than IDL.


> --
> J5

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