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