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

List:       kde-kafka
Subject:    Re: basic design (was Open Issues)
From:       Jono Bacon <f9808590 () wlv ! ac ! uk>
Date:       2000-10-28 19:27:45
[Download RAW message or body]

On Saturday 28 October 2000 09:00, you wrote:
> > > So what is the interest in writing complicated code to handle them and
> > > knowing precisely their nature (IF it is possible) while we _won't_ use
> > > this information???
> > > Storing them as Strings is much simpler and as powerful no????
>
> The DOM is the only storage of information we can use, otherwise the
> complexity will skyrocket. We can basically start with strings but I think
> it is very wise to be able to parse html and create seperate tags for them
> for a number of reasons;
> In the gui we want to display the fact that tags of a specific type have
> been found. (An icon of javascript for example)
> We want to allow plugins in Kafka to be able to use that code. A plugin in
> Kafka could be a full fledged javascript authoring environment. Same with
> PHP or any other scripting language.

I think that the main questions surrounding this extra layer of code in Kafka 
were what use it is. If we are creating generic support for unknown tags  
that plugins can manipulate, then it is a good thing (TM).

the main question is how we integrate this layer so that it is only used when 
required. Should we have this layer as a special module that is only loaded 
when a plugin requests it?

> > > So my question will be : what do you win if you do this plugin
> > > interface against just treating them as strings (and providing an
> > > additional function in KHTML or Kafka, say DOM::PowerLoad() instead of
> > > DOM::load() )???
>
> You win interpretation time, interpreting a string every time in Kafka is
> slow. Creating a specified node in the datastucture is much faster.
> Remember the internal datastructure of Kafka is the DOM!

I didn't know this. Obviously we need Kafka to be quick! :-)

> > I agree that there isn't much point in adjusting the DOM to take these
> > extra tags if we are not going to specifically do something with them.
> > the question we need to ask is "what are we going to do with these extra
> > tags that are in the DOM". Where I can see this new tokenizer being
> > useful is in saving hidden details such as coordinates in the DOM.
>
> That is not true, that would require existing tags (img, table etc) to
> contain extra variables, we are talking about extra tags. Never mind the
> variables _they_ will have.

No...I mean creating Kafka implementation specific tags that could assist in 
making Kafka work better.

> > A second benifit is
> > for new tags that are developed either commercially or at the W3C. We
> > could add them easily with a parser that looks for unknown tags to KHTML.
> > The problem lies when the KHTML developers want to support the tags that
> > we support; there will be lots of checking who has done what and changing
> > codebase.
>
> Ahh, but that is just what this idea was created for to prevent. Extra tags
> in Khtml will be shown and used by Kafka immidiately. The only problem is
> that kafka can not do anything more advanced with it then simply use it.
> But it will never break anything. Again the sole datastructure of kafka is
> the DOM. Allowing a specialized developer to create and maintain the code
> of the datastructure is _only_ in our advantage.

So am I right in assuming that the extra tags would need to be implemented in 
the KHTML DOM, and not another DOM that Kafka would use? All DOM stuff would 
be in KHTML and we just use it. This makes sense.

	Jono

-- 
Jono Bacon - jono@kde.org
KDE/Qt Developer - Founder of Linux UK

_______________________________________________
Kde-kafka mailing list
Kde-kafka@master.kde.org
http://master.kde.org/mailman/listinfo/kde-kafka

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