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

List:       koffice-devel
Subject:    Re: A killer app for KOffice/KDE?
From:       Philipp =?iso-8859-1?q?M=FCller?= <philipp.mueller () gmx ! de>
Date:       2003-02-18 6:58:03
[Download RAW message or body]

On Monday 17 February 2003 16:45, Waldo Bastian wrote:
> On Saturday 15 February 2003 22:09, Adam Treat wrote:
> > This started me thinking ...  KOffice (specifically KWord) can save
> > documents as HTML right now and wouldn't it be interesting to take this
> > feature and create a more ubiquitous network centric document publishing
> > feature.  I am talking about combining the formidable document
> > creation/editing facilities of the various KOffice apps and combining
> > this with a web server/content management suite to create a network
> > centric office suite.
>
> Yup, that would kick ass. A document server with builtin revision control,
> locking, merging, ACLs, web publishing and search indexes. And a facility
> that gives out unique document names / numbers together with a short and
> handy URL to reference such doc on the doc-server. You should be able to
> define document templates that require specific meta-information to be
> registered (e.g. customer number) and after storing such a document on the
> server it should be automatically indexed so that you can get a list of all
> documents related to a specific customer with one click.

Fully agreed here, it would kick ass.

> I think all the building blocks are ready for it, you just need to tie them
> together and make it a ready-to-run package. Pretty much like what the
> kroupware project is doing with mail. If you manage to do that for
> documents I think you have a real killer office app.

No, here it is hard to achieve this for all KOffice apps. Especially the merge 
functionality is rather impossible to do for KSpread.

Just imagine if 2 persons are working on the same sheet and try to merge later 
for the case that one added a formula with a reference to a cell content 
(e.g. [C3]=B2) and the other inserted a row/column which affects the cell 
position (e.g. insert row at row 1).
To be able to merge this, the application server would need to know the whole 
KSpread functionality to be able to merge this correctly otherwise it would 
break the formula. Now add the complexity of different references (e.g. 
=$A$1, ="range") and add the possibility of a lot of cells (e.g. a sheet with 
1000 rows, where there is in one cell for each row a content like =A$2).

It basically comes down to the distinction between soft and hard data. While 
text in KWord is soft data (which means there is no real logic within the 
content), KSpread mostly contain hard data (which means the data has a 
defined logic, which influences itself). The merging of soft data is 
basically easily to do, while doing this for hard data is rather impossible 
to do correctly.

OTOH, what you describe is basically already available since years as a 
commercial product. It's Lotus Notes.
As I think the Lotus people don't make crap, I assume such an app server with 
the corresponding client would basically have the same pro and cons as all 
you would have with Notes (administration, limitations, performance, ...).
And Notes only supports soft data, no real hard data support.

The only thing you can do here is to skip the merging functionality and only  
use a locking functionality. But this is in principle already available with 
all existing CMS/portal software systems. Then I don't see a real benefit of 
having a KOffice centric solution.

Ciao,
Philipp
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]