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

List:       koffice-devel
Subject:    QCA and changes in kstore and kofficecore
From:       Thomas Schaap <t.m.schaap () student ! tudelft ! nl>
Date:       2006-08-18 15:52:57
Message-ID: 44E5E259.2020307 () student ! tudelft ! nl
[Download RAW message or body]

Hi,

I've been working on incorporating support for encrypted documents in 
KOffice over the last weeks. Now I've reached the point where I'm about 
to commit some things. Yet I should first pose two questions to all you 
KOffice developers out there, since some changes are going to be noticed.

First of all, there is need to use some encryption functionality. No, 
I'm not kidding, I actually found I need it. I've been searching around 
a bit and found that QCA is the best candidate as a framework: it's 
based on Qt, can plug in many cryptographic libraries as providers, and 
is also available on the KDE svn. So far, nothing bad, I hope. The issue 
is that KOffice will depend on QCA for encrypted file support. Though I 
currently have QCA as required in my own local copy, it seems wise to 
change this to optional (no QCA means no encrypted files). What I'm 
wondering about at the moment is whether I should give a warning to a 
user when he compiles KOffice without QCA being present. Also I'm 
looking for someone who could help me a bit with the cmake files: I sort 
of got things going, but it doesn't seem very stable to me, nor is it 
optional at the moment.

The second issue is one that touches the internal structure of KOffice. 
I have implemented the support as a KoStore in kstore, because this is 
by far the best place to do so: it's the level where the packaging 
should be (un)done, as well as any compressing. Since files in an 
ODT-document are compressed, then encrypted and then packed, the 
en-/decryption part is also in kstore. The encryption data, however, is 
stored in the manifest file, an XML file. Therefor I need support for 
reading an XML file in kstore. I could of course use the QDom 
implementation, yet KoXmlReader seems to be faster and gives all I need. 
It is, however, currently placed in kofficecore, where I can't use it 
from kstore. To solve this problem I've been looking at relocating 
KoXmlReader in kstore and I think it makes sense:
- it deals with storage-interpretation (storage of meaningful data in a 
file);
- it is not really that specific to kofficecore that it would be wrong 
to put it outside kofficecore;
- KoXmlWriter is already located in kstore, it would make sense to put 
the two of them in the same library.
I'd like to know opinions about this: should I simply move the file (and 
make sure nothing breaks :D), should I find another solution?

Yours truly,

Thomas Schaap
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]