Hi, I'm going to be applying for the GSoC with KDE/KOffice and I was 
hoping I might get some feedback on my proposal from the developers of 
KOffice.
Any suggestions or criticisms would be immensely valuable. Thanks!
*
*
*Summary*

As developers, we are all too aware of how useful keeping multiple 
versions of a file can be.   OpenOffice.org currently features a similar 
ability to save multiple
versions within a single OpenDocument file.   This is potentially very 
useful to end users as it allows for them to maintain multiple versions, 
without the hassle of
maintaining and organizing multiple files.   I believe KOffice, if it 
wants to compete with OpenOffice.org, ought to offer this great feature 
to their users.

The ability to save versions is wholly separate from the ability to save 
a file.   While a file may be a version, the ability to hold multiple 
version of a file concurrently
within one single file is much more useful.   Now there are six 
different OpenDocument file formats, four of which are used by

*Goals*

My goal is to implement support for storing and retrieving multiple 
versions of a document, using only a single OpenDocument file. This will 
require adding this type
of support for loading and saving versions within the KOffice 
applications which utilize one of the OpenDocument formats. This will 
enable the user to store multiple
versions of the same document without having to save multiple files and 
keep track of them. This is potentially useful for many reasons. One can 
experiment with
edits to a document without having to worry about destroying the 
previous "good" version. With this feature, it should also be possible 
to make multiple versions of
a single file, which differ only in their style--effectively allowing 
the user to try out the different styles easily. But beyond it's use to 
the users of KOffice, this feature
will also allow KOffice to gain a feature which OpenOffice.org currently 
has.

*Implementation**

I am currently looking into two separate ways to implement versioning. 
The first method is to implement something like OpenOffice.org did, 
where there is a version
 list file which lists the information about the various saved versions 
and a separate folder where the information about the different versions 
are stored in separate
"zip" files which contain their individual, complete version.

The other option is to use the change tracking features within the 
current ODF v1.1 specification along with some additions to implement a 
versioning system that
functions more like a version control system, tracking changes to 
individual sections of a document, than an archival system which retains 
copies of previous versions.

*Time Line*

I plan on spending the time running up to the start of the Google Summer 
of Code and the first week in deciding how best to implement versioning 
within a single
OpenDocument file within KOffice. Once I've figured out how best to 
implement the feature, I will implement the ability within each 
application, starting out with
the applications using the .odg and .odf formats, since there are 
approximately two applications which use the .odg and approximately 
three that use the .odf file
formats. These should go faster since they could possibly share some of 
the code between the applications. I hope to have those done by the 
midterm, after which
I will implement the support for KWord and .odt, KPresenter and .odp, 
and KSpread and .ods. This should be an attainable goal by the end of 
the Summer of
Code, but, understanding that problems always occur in development, I 
plan to keep a flexible schedule. My ultimate goal is to implement as 
much of this capability
within the summer, and to implement the rest during the fall.

*Qualifications*

I am a freshman/sophomore Computer Science student at the University of 
Maryland, College Park (www.umd.edu and www.cs.umd.edu). I have experience
developing with C++ and Java and knowledge of Python and XML. In 
addition, I am familiar with the KDE, Qt and KOffice APIs and I am an 
active contributor
to the KOffice project. I have submitted one patch for KWord, and am 
working on a second patch for KWord.   This familiarity will allow me to 
begin work on
the project quickly as I won't have to spend any time learning the Qt, 
KDE, or KOffice APIs.


*My Implementation details are a little vague, as I haven't nailed down 
a specific implementation which is best.
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel