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

List:       koffice
Subject:    [Bug 120553] New: colaboration support including versioning
From:       Raphael Langerhorst <raphael.langerhorst () kdemail ! net>
Date:       2006-01-21 12:30:44
Message-ID: 20060121133036.120553.raphael.langerhorst () kdemail ! net
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=120553         
           Summary: colaboration support including versioning (subversion)
           Product: koffice
           Version: 1.4.2
          Platform: Compiled Sources
        OS/Version: Linux
            Status: NEW
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: koffice kde org
        ReportedBy: raphael.langerhorst kdemail net


Version:           1.4.2 (using KDE KDE 3.5.1)
Installed from:    Compiled From Sources

This wishlist is to avoid an unmaintainable mess of files on your harddisk.

Groups of people (like companies) work on many documents, also, they usually need to share them \
and colaborate. This comes down to the need of a central and versioned document storage \
facility - in order to avoid endless sending of documents to and from with emails or working on \
a number of different versions on a (network) file system. Ideally this facility should be able \
to manage access restrictions to users.

I picture this in three steps:

1) Implement Subversion backend support
2) Implement Access Control, in connection with some other groupware facility like Kolab2 or \
just LDAP (Kolab2 uses LDAP). Subversion must of course authenticate then against these things \
(LDAP), which is possible using Apache (AFAIK). 3) KOffice should be able to compose a document \
from a hierarchy of files which are in themselves small documents (some of them again "master" \
files of yet another collection of subdocuments).


Step 1) Subversion backend support

This would be rather simple to do, maybe it even IS already implemented... hmm... let me \
check... yes to some degree it already works, at least opening a file from within Konqueror \
with the URL https://raphael svn kde org/home/kde/tunk/koffice/doc/CookBook odt gives me a \
kword instance that shows this URL as filename. Saving my changes fail - it seems \
authentication somehow doesn't work from within kword, although it displays the password \
dialog. svn:// URLs don't load. It seems that KIO for these things isn't fully functional(?) So \
the technical backend support has to be provided by kdelibs, not koffice.

But apart from just opening and saving files from/to svn it should be more integrated in \
koffice itself. That is, if a versioned document is loaded, a listview on the right \
could/should give a choice of version, and maybe be able to view differences between texts of \
different versions.

Another "browse" view could be used to browse the repository online and chose files for \
editing. This should work like a sketch board, where multiple files can be edited at once and \
switched fast. I think koshell (KOffice Workspace) is already providing that kind of thing, so \
it only needs online repository browsing added.


Step 2) Groupware support

Next step would be to find a working mechanism for colaboration. That is, the document owner \
should be able to define access permissions to his documents. This might be done through an \
LDAP authenticated subversion repository. I think groupware support is also related to the next \
stept - splitting of documents.

Thinking of LDAP authentication: Existing users managed in the Kolab2 administration interface \
can be the same users for the subversion repository. The user can chose permissions for users \
right from his address book(!!)


Step 3) Documents composed of an hierarchical file structure

I think a major important functionality must be the ability to create hierarchically structured \
documents, in the sense of composing a document of multiple files. This shouldn't be just one \
layer of master-document + content-documents. Instead, it should be a tree of "any" depth with \
one root document.

An important aspect is style inheritance in this case I think. I would propose the following: \
All existing styles in a parent document are propagated (and synchronized on change!) to the \
child documents. This being done recursively makes sure that all styles are in sync as well as \
private styles of child documents are not seen in the parent document - think of scopes in the \
sense of programming.

The advantages of this is that individual parts of a document can be edited by individual \
people - colaboration.

With this in place, KOffice would rock, especially for large-scale installations.
____________________________________
koffice mailing list
koffice@kde.org
To unsubscribe please visit:
https://mail.kde.org/mailman/listinfo/koffice


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