'Re: [quanta-devel] What is next?'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] What is next?
From:       Eric Laffoon <sequitur () easystreet ! com>
Date:       2005-03-03 23:41:33
Message-ID: 200503031541.33277.sequitur () easystreet ! com
[Download RAW message or body]

On Thursday 03 March 2005 12:43 pm, Paulo Moura Guedes wrote:
> On Thursday 03 March 2005 20:14, Andras Mantia wrote:
> > On Thursday 03 March 2005 21:43, Paulo Moura Guedes wrote:
> > > The question is, are the Quanta team, especially Andras, willing to
> > > do such a thing, if we conclude it's the right step?
> > > I guess the question must be yes, if we want VPL in Quanta.
> >
> > Uh, do you realize what are you asking? You know, I will happily use any
> > other parser or node tree if it provides what we need: quick updating
> > as you type and good error and context handling.
> >  I have no idea about what KDOM does, but remember that Quanta is used
> > for a lot more than XML. CSS/PHP is anything but XML, but it is still
> > parsed. For example how does it deal with:
> > <body
> >  <?
> >     </body>
> >   ?>
> >
> > </body>
> >
> > We must know that <? ?> is a PHP area, and the missing ">" after body
> > should not confuse the parser and the node tree.
> >
> >  So I cannot pronounce until I see what this is all about, but I fear
> > that we will not be able to use it.
>
> I perfectly understand your concerns.
> I don't know how difficult it would be to extend kdom to our needs, that's
> why it would be interesting to hear what Niko has to say.

We're always open. We reserve optimism when it comes to parsers. ;-)

> In kdom DESIGN document it is written "We want a stand-alone DOM
> implementation, not tied to any specific application like HTML, XML or
> SVG." which is a good sign.

Yes... but think of the mission. I read in this they're saying a universal XML 
parser, like we're doing with Quanta. I don't read into this anything about a 
capable scripting parser for non markup like PHP and Javascript. Ironically 
though both types of parsers are being done elsewhere in KDE. There is though 
the matter of consistency we have achieved in ours and the very carefull and 
painfully refined optimizations. I for one would be ecstatic if all the 
parsing efforts in KDE could be unified and perfected, but I'm not sure it 
could be done at this time given optimization tradeoffs and average 
processing power, not to mention the monumental task of coding it.

> Anyway, thanks for your open mind Andras.

If you look at the time Andras has put into the parser and the fact that it's 
still not quite where we want it you would see that having a parser we could 
adapt would be an epiphany for development. At the same time it should be 
obvious that transitioning has the potential for an agony of a bugfest.

I would not want to sound less than excited, but the fundamental assumption 
for most parsers unfortunately does not include our hybrid needs.

Eric
>
> P.S. Nikolas, there are plans to extend kdom's documentation, like adding
> some simple examples of what one can do with kdom?
_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel
[prev in list] [next in list] [prev in thread] [next in thread] 