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

List:       koffice-devel
Subject:    Re: GSoC Proposal - Versioning within OpenDocument files
From:       Nicholas Sinlock <isolatedincident () gmail ! com>
Date:       2009-03-17 16:36:17
Message-ID: 49BFD181.3080709 () gmail ! com
[Download RAW message or body]

Thomas Zander wrote:
> On Monday 16. March 2009 23:57:13 Thomas Zander wrote:
>   
>> Bottom line; I want to feel you are already aware on a global
>> implementation level of how this is going to work. If you are fresh at the
>> koffice codebase then this project is just too big for a GSoC.
>>
>> If you have a proposal of working on something that doesn't come so close
>> to what others are also working on (text/odf/change-tracking), that would
>> have my preference.
>>     
>
> Someone asked me off-list to elaborate on this; fair enough :)
> As PiereSt mentioned there are two approaches; I was actually only aware of 
> the one that is storing differences. Which is an approach I think is most 
> valuable for our long term goals (which include collaborative editing[1])
> In line with that thinking I have to say that it doesn't make much sense to 
> have the GSoC depend on not-yet-written code that PierreSt wants to create. 
> And as long as you two don't sit in the same office I think working on the 
> same concepts just doesn't work.
>   
First, I think Pierre's idea of a snapshot version is exactly what I was 
going for with my proposal, as that
is exactly what the OOo versioning system is. It's a "side feature" 
which allows for the creation of snapshots
of the file at a certain moment in time.  I'd wanted to see about using 
change tracking to implement the ability
but even if the code WAS there, it'd be too much work for a GSoC.  That 
being said, I don't need to rely on
change tracking to implement a snapshot versioning system similar to 
OOo's.   This has several advantages.
First, it can leverage a lot of the existing ODF/XML tools, which means 
it would be small enough to
implement in a summer.   Second, the beauty is that once we have change 
tracking, one could go back and
reimplement it using the change tracking, as well as adding a lot more 
functionality, as you pointed out Thomas.

I'd argue it's worthwhile to implement that system now, since we can, 
rather than wait for change tracking, due
to the difficulties Pierre pointed out.   This feature can be done now 
in this manner.  Even if it's "inefficient", it's
a good start, and a more comprehensive system based on change tracking 
would be better, but will take more
time to implement since it requires not just change tracking, but all of 
the other features mentioned by Pierre.

I'm working on the second draft of my proposal, which will include more 
of the details.  So, hopefully I will be
able to convince you.   But Thomas, I am not sure if I understand you 
about one thing.   Are you saying that you
 don't want GSoC students to deal with any of the core apps code at all?
> In KOffice2 we have made the power of adding feature via plugins much more 
> clear than it ever was.  For that reason I think we should try to get any 
> GSoC working on projects they can do in a plugin. This is much better for 
> starting developers as they can work on their own pace and avoid depending on 
> others or others on them.
> I'd like to keep the amount of people working on the core apps+shapes down as 
> communication and coordination is essential. Or at least a clearly shared 
> vision. Which I don't expect new SoC students to pick up immediately.
>
> A great example of a successful project is the musicShape.  Its maybe even 
> something that one might want to continue working on :)
>
> Hope that helps!
>
> 1) http://wiki.koffice.org/index.php?title=Collaboration
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>   

_______________________________________________
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]