OCT
23
2001

KC KDE Issue #22

After a two month hiatus, I am happy to report that
Aaron J. Seigo is back with
another issue of his fabulous Kernel
Cousin KDE
. This issue, which covers the week of October 8-14,
touches on wide-ranging topics such as KDE3, some new KIO Slaves, a new KDE
XML editor
, the new KDE PIM site, the
new KDE address book, and many other exciting developments. You can read
Aaron's well-written synopsis
here.
(And thanks to Aaron's suggestion I have created a
new
category
for KIO Slaves.)

Comments

http://kt.zork.net/kde/latest.html is the link to the latest issue of KC KDE. And why can't I post in HTML? Weird.


By Erik Hensema at Tue, 2001/10/23 - 5:00am

> And why can't I post in HTML?

Because I'm a lazy dork. ;-) As one of the most requested features, I will have to get this done eventually...

To get back on topic, great to see KC is back! It's really tough following KDE devel progress without it.

Cheers,
-N.


By Navindra Umanee at Tue, 2001/10/23 - 5:00am

Navindra,

Is the dot stuff code in PHP? If so, I can contribute some code (about 40 lines) that is sort of an html firewall of sorts. You pass the body through a preg_replace routine call that itself calls a routine to check each html tag and element. It allows only tags that you have designated as "safe" via an inclusion within an array, and can also bar "safe" tags that carry "unsafe" elements. Any unsafe html can be removed or converted to a safe format.


By Sean Pecor at Tue, 2001/10/23 - 5:00am

We could patch in a PHP solution, but a native solution does already exist... I'm just a lazy dork. Thanks for the kind offer!


By Navindra Umanee at Tue, 2001/10/23 - 5:00am

And ofcourse there are people like me who like a forum without html postings. It kind of gives every posting a consistent look.
IMHO html mark-up muck is too often used by people who want more attention then they deserve.

Johan V.


By Johan Veenstra at Wed, 2001/10/24 - 5:00am

Wow, good work Richard! Now we have TWO editors for KDE. XML is definately an area I'd love to see KDE3 "konquer". I wonder how much Richard means when he says "make maximum use of the facilities offered by KDE and Qt"... Personally I'd love to see this project mature into an XML equivalent of KDevelop, with a feature set comparable to XMLSPY. Also, I wonder if anyone is interested in developing an XML toolkit for KDE, with DTD/XSchema validation, XSLT, XLink, XPointer, XPath, and RDF support built-in. This is one area Microsoft is definately getting ahead. If we could provide a componetized XML framework for developing XML and Web services, developers would flock to KDE (even faster than they are now ;-). I'd like to see Konqi become an XSLT-enable browser, too. Guess I should stop now and just continue to cheer on all the excellent developers. Go KDE!

Eron


By Eron Lloyd at Tue, 2001/10/23 - 5:00am

Most of what you want can be done with libxml, it "just" has to be integrated, e.g. into Kate. For editing XML also see my Kate Plugin at http://www.danielnaber.de/tmp/ -- if someone wants to add libxml support to it, please do so (I'm too afraid of plain C).


By Daniel Naber at Tue, 2001/10/23 - 5:00am

My understanding, though, is that libxml would be phased out while migrating to KDE3, in favor of a more "natively" integrated library. libxml, while it seems like a good library, I believe is directly targeting GNOME. However, it does seem to have a large potential capacity. I believe Redhat is funding Daniel at the moment. It wouldn't surprise me if Qt began extending built-in support beyond DOM & SAX in the near future. Thanks for the suggestion.

Regards,

Eron


By Eron Lloyd at Tue, 2001/10/23 - 5:00am

No, it is not directly targetting GNOME. It does not depend on
any GNOME/Gtk/GLib library, it uses different API conventions,
and it is distributed under a lot more liberal license (BSD like).

It is also unlikely that Qt will ever have a validating parser
or do stuff like XSLT. It simply does not make sense for a
GUI library.


By Bernd Gehrmann at Tue, 2001/10/23 - 5:00am

On the contrary, Qt is _much_ more than just a GUI toolkit; it's a full application framework. Thus the inclusion of networking, database, XML (DOM & SAX), etc. I hope that people begin to realize this.

Also, can anyone confirm that there WILL indeed be a move to deprecate libxml in favor of a more native component? I can't find it in my list archives...

Regards,

Eron


By Eron Lloyd at Wed, 2001/10/24 - 5:00am

It's a "full application framework" for the development of GUI
applications. GUI applications nowadays have a need for saving
and loading XML documents. For that, DOM is the most natural
API, and SAX is practically a "byproduct" of the implementation.
There is no need for XSLT in a GUI application.

And honestly, I don't even see why anyone would want to reinvent
a good library anyway. libxml is widely used, actively maintained,
it's stable, reliable and standards compliant.


By Bernd Gehrmann at Wed, 2001/10/24 - 5:00am

Agreed. However, getting back to the discussion of having a well-integrated XML library for KDE, anyone who knows XMLSPY well knows that it is build on top of what? MSXML & IE. True, libxml is quite impressive for being such a young project, but there are _many_ areas of KDE that decided upon creating their own libraries vs. using an existing one (i.e. KTHML instead of Gecko). I myself am not qualified to take this argument too far, as once faced with the question, "So what are YOU gonna do about it?", I honestly am not experienced enough in KDE/Qt development to create such a beast. However, people reinvent libraries all the time, and I can remember not much more that three years ago people would argue that there is no need for good HTML rendering classes in a GUI library as well.

So I must disagree with you that including these capabilities would not be attractive to developers, as I know quite a few developers that would _LOVE_ to know that KDE provided a good API for the full spectrum of XML technologies, and would be ecstatic if it were provided as a cross-platform solution as part of Qt. I think widgets will have a need for end-to-end XML handling just as much as they now can talk to a SQL database. I guess our problem is just that XML is still barely into the mainstream, so determining the proper roll-out of functionality is still an immature process.

*shrug* - fortunately it's still early in the game, and with the rate the KDE project has progessed in every other area, I'm sure we'll see some exciting XML developments in the near future as well.

Cheers!

Eron


By Eron Lloyd at Wed, 2001/10/24 - 5:00am

I have not claimed that it is not attractive to developers. I have
said that everything you need is provided by libxslt. Applying an
XSLT script is almost trivial. Just parsed your XML file with
xmlParseFile() (or use the appropriate in-memory API), parse your
style sheet with xsltParseStylesheetFile(), apply it with
xsltApplyStylesheet(). If there are any external entities you
must resolve, install a handler with xmlSetExternalEntityLoader().
It's all very easy :-)

Of course, you can also write a little wrapper that feeds
strings from a QIODevice or writes data to it. It's certainly
not more than 200 lines of code.


By Bernd Gehrmann at Wed, 2001/10/24 - 5:00am

Well, I must trust your good judgement, and will devote some more time to have a close look at libxml/libxslt. The only real reason I am uncertain of it's use is because I remember (please don't quote me on this one...) someone like Kurt Granroth or David Faure mentioning several months ago on the kfm-devel list that libxml would eventually be replaced by something else for some reason or another. Not sure exactly, tho'.

Have a great day!

Eron


By Eron Lloyd at Wed, 2001/10/24 - 5:00am

Thanks, for your positive comments. What I mean by making maximum use of KDE and Qt, is that where I can I'm reusing existing components - the JS engine is kjs, the source view is Kate, the rich text editor is QTextEdit... In addition, when the existing components aren't sufficient, I've tried to make the new ones I've written generic so they can be reused in other apps. For example, the JS-QObject bridge and the JS-QWidgetFactory bindings are usable standalone and could simply be dropped into another app.

Thanks for pointing me towards xmlspy, I hadn't looked at it before. I don't think xmelegance will be competing with it for a while though - there's still a fair bit of work to get the basics written.

Cheers

Rich.


By Richard Moore at Tue, 2001/10/23 - 5:00am

Wow! I'm really impressed. The software engineering community talks and talks and talks about component-oriented design and the reuse of components, but KDE really does it. Given the funcionality you've put together, XMElegance seems to be a shining example of component reuse.


By Justin Donnelly at Thu, 2001/10/25 - 5:00am

I agree 100 %. XML Spy is one of the best programs I have ever used in Windows. Instant validation both according to DTD and Schema, "form based" input according to schema, and the graphical views are excellent. It amazes me that they can develop this product so fast when the XML world in turn is moving so rapidly. What I think is the best thing with XML Spy is that it gives you both: both text based editing with syntax highlighting, and graphical views for people that do not know schemas so well. It also follows very advanced schema features , it parses 10 dependent schemas without a problem, and immediately finds problems in the dependencies.

If KDE could get something like this it would rock!


By Claes at Wed, 2001/10/24 - 5:00am

hi there,

worked with kde and zope for about a year and following xmleditor. i'm now with a major telco on a proof of concept with biztalk, also took part in a dotNET developer meeting lately. since i find opensource and spec. kde rocks i'd like to see it lead.

i got fairly interested into what the competition (M$) is upto with xml. since i'm not a developer i hope to help with an analysing view:

in BizTalk there are two programs offered
Editor to edit (and convert) XML Schemas (and DTDs, EDIfact ...) and an Mapper with a left and a right pane where you load two XML schemas. by Drag'n'drop one can connect (map) Elements and attributes to each other with socalled FUNCTOIDS in betweeen (computing nodes in IBM Websphere MQ Integrator). the functoids are intelligent (scriptable) conversion nodes. all this gets compiled into an XSLT. really smart and easy to use compared to the sheer complexity of XML Schema and XSLT.

IMHO KDE will eventually needs something like these functionalities to compete. it shouldn't be so hard to do anyway.

dotNET's WebService technology on the other hand is really basing to a vast extend on XML. there are three areas in the class lib that each have their right for beeing.

1. is with basic functionality (like SAX one said) to read/write element by element
2. is a DOM implementation to read a file into ram
3. is a XPath basing implementation for large files. this allowes also to extend the functionality (e.g. to read the filesystem+file as one big XML document) (really sweet).

anyway the absolute killer seams to me that there is a possibility to just convert the data structure of a class into an XML Schema and other way round. since there is some data missing in a class definition (element names, parameter as attribute or element) they introduced something called
"attributes" (in []) into their languages (VB.NET and C#). as you know there is a gnu effort to bring the virtual machine (CLR) to Linux (http://www.go-mono.org). what is more they do a library (DLL) -- WSDL matching in their IDE. this is so easy (just add the (file-)path to the library or the url to the WSDL file to the project and you even have intellisense in the IDE to use this (web-)service.

this is one way M$ makes it easy for developers to use webservices. no more header files, no more xmlrpc trouble with structures ... and please i do not say it always makes sense. but that is the decission of the developer :-)

such tools and ide integration might eventually help the guys in the PIM conduit area the most and might also lead to a XML based messaging (missing in KDE/GNU/Linux) for loose and asynchronous process coupling. M$ has MSMQ, IBM has MQSeries BTW.

would love to see easy webservice development (e.g. based on zope and kde :-)

thanks for your time and these great kde apps

maxwest


By maxwest at Wed, 2001/10/24 - 5:00am

If you have a remote machine with ssh access, please install kio_fish mentioned in the KC KDE #22. Its so cool ! On Konqi open "fish://user@remoteserver" enter the password/passphrase and voila , no SAMBA no NFS , and everything is SSH encrypted .


By hackorama at Wed, 2001/10/24 - 5:00am

This is SO COOL! I love KDE!

Now, I can automatically browse all my files on the CS department server across campus using Konqueror, AND edit them in place across the network using Kate! Encrypted, too!

KDE really has some amazing technology under it. Keep up the good work, KDE developers!


By not me at Wed, 2001/10/24 - 5:00am

I've really missed these!


By Joergen Ramskov at Wed, 2001/10/24 - 5:00am

For an XML library, if Qt's is not going to be used, why not try Xerces-C? It is
an Apache project and I hardly ever see it used for anything. The library was implemented
entirely in C++, not C like expat, libxml, etc... Not that C is bad, just that since
KDE is written in C++.


By AC at Thu, 2001/10/25 - 5:00am

For an XML library, if Qt's is not going to be used, why not try Xerces-C? It is
an Apache project and I hardly ever see it used for anything. The library was implemented
entirely in C++, not C like expat, libxml, etc... Not that C is bad, just that since
KDE is written in C++.


By AC at Thu, 2001/10/25 - 5:00am

Navindra, when you get off your lazy bum and add html posting, fix that duplication bug too! :-)

Seriously, it's just a matter of saying :

Upon any attempt to post a comment, if there is another comment posted on the same thread with identical message content and poster name, then don't create this new posting.

You don't need to fix the problem of browsers reposting when you hit back, browsers stopping after submitting but before getting info on the next page to display, etc. In fact, you don't even need to display an error message when this happens.


By Carbon at Sun, 2001/10/28 - 5:00am

As a hack slap-on-the-side, just hash the message with something like MD5, and create a file with that name in a directory. If the file already exists, forward the user to an error URL, and don't post the message. Add a cron job to clear the directory once a night.

Very cheap, easy solution that should work without having to dig through lots of code and figure things out. Not the best, but it'll be better than this.

--
Evan


By Evan "JabberWok... at Sun, 2001/10/28 - 5:00am

There's really no need to do that. I mean, for one, why send them to an error message, when the user is likely to think that they didn't post at all. Imagine this scenario:

User goes to post a comment, hits add, waits 10 seconds, gets impatient and hits stop, then hits add again and recieves an ... error message telling him his comment wasn't posted. The server thinks he's posted twice, and ignores the second, letting him know, but the user will think he hasn't posted at all, since he never got confirmation for it the first time.

Sure, the message might explain that the message was actually posted before, but what's the point? All the user wants to do is post one comment and recieve confirmation of that, and if that happens, than the operation (irregardless of how many times they clicked "Add") was successful.

Rather, in the event of a duplicate post, it should just act like they posted normally, give normal confirmation, but not actually insert the new (second) message. I really can't think of a non-troll reason why anyone would want to post an identical message twice to the same thread within a short period of time.

Plus, placing hashed messages in a directory is just duplication of data that the server is already storing elsewhere. The server is even storing timestamps of each posting, so you could just add "within a set period of time" as a qualification to my message above.


By Carbon at Sun, 2001/10/28 - 5:00am

I agree.

--
Evan


By Evan "JabberWok... at Mon, 2001/10/29 - 6:00am

There's really no need to do that. I mean, for one, why send them to an error message, when the user is likely to think that they didn't post at all. Imagine this scenario:

User goes to post a comment, hits add, waits 10 seconds, gets impatient and hits stop, then hits add again and recieves an ... error message telling him his comment wasn't posted. The server thinks he's posted twice, and ignores the second, letting him know, but the user will think he hasn't posted at all, since he never got confirmation for it the first time.

Sure, the message might explain that the message was actually posted before, but what's the point? All the user wants to do is post one comment and recieve confirmation of that, and if that happens, than the operation (irregardless of how many times they clicked "Add") was successful.

Rather, in the event of a duplicate post, it should just act like they posted normally, give normal confirmation, but not actually insert the new (second) message. I really can't think of a non-troll reason why anyone would want to post an identical message twice to the same thread within a short period of time.

Plus, placing hashed messages in a directory is just duplication of data that the server is already storing elsewhere. The server is even storing timestamps of each posting, so you could just add "within a set period of time" as a qualification to my message above.


By Carbon at Sun, 2001/10/28 - 5:00am

I agree.

--
Evan


By Evan "JabberWok... at Mon, 2001/10/29 - 6:00am