Design

[GoogleCodeExporter]

Over at the cplusplus.com forums someone suggested we should seperate the 
interface and the functionality. I think this could actually be a good idea. 
We need to take a few things into consideration here:

1. Will all the dialogs for the algorithms be the same? If so, we can do with 
one EncryptDialog which holds a pointer to a class which performs encryption.

2. Each algorithm would be a derived class of base EncryptionAlgorithm.

3. This would make it very easy to perhaps compile an encryption library later 
on for use for the members over at cppforum.nl.

4. In my opinion this could make the code a lot cleaner. We should not fear 
huge design overhauls, certainly not this early on in the project. 

This issue should be sorted out before we continue.

Original issue reported on code.google.com by xander.deseyn on 24 Jan 2012 at 8:21

[GoogleCodeExporter]

I agree, so encryption algorithms will now be derived from a class called 
EncryptionAlgorithm.
This class should have a function to retrieve the name of the algorithm, this 
function is reimplemented by it's children or it's children tell the 
constructor of EncryptionAlgorithm what the name of the algorihtm is.

EncryptionAlgorithm should also have 2 pure virtual functions:
void encrypt(istream& in, ostream& out) throw(cryptError);
void decrypt(istream& in, ostream& out) throw(cryptError);
This means we'll also have to create a cryptError class which can be thrown by 
the encrypt and decrypt functions to report any errors.

We also have to decide whether the seperated encryption lib we're writing will 
only need the STL or can also use Qt or other libs.
If it only uses STL, it's easier for other people to install and use it.
On the other hand, other libs can offer useful functionality.

Original comment by Divendo1180@gmail.com on 25 Jan 2012 at 3:30

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

I don't know how we will be able to accomplish stuff like checking if it's a 
valid directory path in STL, but since we don't use Qt for the algorithms 
themselves it shouldn't be such a big change. And are we sure about using 
exceptions?

Original comment by xander.deseyn on 25 Jan 2012 at 4:49

[GoogleCodeExporter]

Nevermind I found out how to do it with STL.
But I ran into another issue: The parameters for our encrypt and decrypt 
functions may differ for each algorithm (eg RC4 needs two keys)!
How do we go about this?

Original comment by xander.deseyn on 25 Jan 2012 at 5:50

[GoogleCodeExporter]

Nvm got a solution. I was being dumb haha!

Original comment by xander.deseyn on 25 Jan 2012 at 6:24

[GoogleCodeExporter]

Original comment by xander.deseyn on 27 Jan 2012 at 4:54

• Changed state: Done
• Added labels: Type-Review
• Removed labels: Type-Defect