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

List:       kde-edu-devel
Subject:    Re: [kde-edu-devel] And so it begins (libkdeedu)
From:       Ewald Arnold <ewald () ewald-arnold ! de>
Date:       2002-05-30 16:57:20
[Download RAW message or body]

Hello,

> I too would like to see some real tests on how this performs comparatively.

yes, that's what I wanted to find out :-) Implement both ways basically and 
just try and compare benfit and cost both of implementation and usage.

> If we decide to use a SAX based approach, we will have to redo much of the
> work that QDom does.  We will have to keep track of the parsed elements in

I don't think so. It rather is a matter of *when* you invest the time and 
code: while reading as in sax or after parsing as in dom. I also think that 
dom will be slower as you either walk through your tree on and on or you 
implement "shortcuts" with pointers or arrays which results in redundant data 
and potential bugs. dom is certainly convenient and maybe easier to 
understand but you have to pay for it.

> be libkdeeducore and libkdeeduui.  And if we ever get things going with

I was also thinking about "core" but "core" can mean a lot :-) But I agree 
with your names.

> KParts that might merrit another lib, but we can make that decision when we

kpart will be part of the gui element as it only offers an interface.

> Also what do you think about the prefix KEdu for the classes?  I know these

yes, agree

> KEduData[...].  Can/should we assume that this will be _the_ data format
> that we use or should we treat these specifically as "vocabulary" data?  I
> obviously chose the former, but if anyone thinks otherwise I'd like

From my point of view we should support everything that fits into some kind of 
xy-matrix or table: 
 - One or more elements from top to bottom. 
 - One or more items in those elements from left to right that may contain 
arbitrary properties: vocabulary text, sound, pictures

><o> and <t> identical in all of the attributes that they accept (and if so 
>will this always be true)?  If so, I think it makes sense to make them our 

yes, <o> and <t> are basically the same. <t> contains some additional 
attributes like grade or query date since there may be more than one <t> and 
storing them in <t> was easier.

There should be several levels of abstraction in the api based on the above 
"elements" and "items". Generic classes are built-in for rather simple apps. 
More specialized apps then need to derive from one of the existing classes. 

BTW: I have moved my "ideas" directory to the new libkdeedu directory. I have 
stored some of the emails of today there so we won't forget them.

cheers
Ewald

-- 
Ewald Arnold, Germany
http://www.ewald-arnold.de/
mailto:ewald at ewald-arnold.de
mobil/sms:+49-162-8001240

_______________________________________________
kde-edu-devel mailing list
kde-edu-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-edu-devel
[prev in list] [next in list] [prev in thread] [next in thread]