I figured it's about time I write down some thoughts on the future of fSekrit in one (hopefully coherent) thread, rather than having bits and pieces spread across various other threads. So, without further ado, here goes a braindump
Current state of fSekritThe program is relatively close to being feature-complete, at least in the context of the features I originally envisioned. A few of the unimplemented features require a
fair amount of code, however, feature
count isn't everything.
Not all code is as clean as I would ideally want, there's a fair amount of commenting and documenting to be done, and a bunch of refactoring as well. Work has been started on this.
There's currently no test suite, which is... pretty bad. There's been a few bugs that a test suite would/should have caught. Never really found any C++ unit testing framework I liked, but I recently bumped into
gtest which actually looks pretty decent.
Feedback?Overall, I'd say that the project is in relatively good shape.
fSekrit in the futureKeywords:
- Modularizing - progressing nicely, "sekritCore" close to done.
- Documentation - update & cleanup existing. (Internals, not readme.txt)
- Unit testing - not started.
- Key derivation - implement PBKDF2 instead of sha256(passphrase).
- Tabbed interface - multiple "document streams" in one container. Work has been started.
- Mass upgrader - automate upgrading of editor part of documents.
- Open-source - unleash the source code unto the world.
The current goals are towards cleaning up the source code, before new functionality is added. This means modularizing, documentation, unit testing. Work is progressing nicely (load-code has been refactored & works, save is yet to come), but there's still a fair amount of work to be done. Executable size has bloated a bit, but once unit tests are in place and refactoring is done, some code will be specialized instead of using standard C++ containers, which should bring code size down to the size of 1.40 - perhaps even a bit smaller.
Once cleanup is done, I'll have to decide on whether I want to open-source the project first, or if some of the missing features should be implemented. I'm leaning towards open-sourcing first,
perhaps implementing PBKDF2 first.
Feedback?Opensourcing fSekritI've been wanting to do this for a while, it's something that has been planned pretty much from the beginning. I didn't want to release the code before it is "decent enough", though - I'll have to admit that some revisions haven't exactly been top-grade code
There's various decisions to be made wrt. opening the source. One of them is license - it's definitely
not going to be the horribly yucky GPL. Basically I don't want anybody making money off my work, I want attribution if my code is re-used, and I'd
prefer to stay in charge (though this last requirement needn't be enforced in the license).
Feedback?There's also the issue of hosting. Forum and binary downloads probably still fit just fine on donationcoder.com and dcmembers.com, but I'm not sure what to do with the source code. I'm considering SourceForge or GoogleCode, dunno if there's other/better choices.
Feedback?At least initially, I'm going to keep the subversion repository on my own private server, and let people contribute patches if they want. Source code previous to the open-sourced version won't be public available. Eventually, it'd be nice to have updates to my own repository mirrored to a public repository; this really screams "move to a DVCS".
Feedback?I might want some bug tracking / feature request system as well... that would probably come with the source hosting. I've used RedMine a bit, and that's the one I've been liking best - trac is apparently nice, but looks a bit unpolished.
Recent Posts
- pretty sad that this is the opensores audio editor "flagship".
