[odf-discuss] News on MS pluggin

[marbux]

On 10/16/06, Thomas Zander <zander at kde.org> wrote:
>
> The building of a better mousetrap based on the current requirements and
> user
> requests does not in my mind have to lead to any server side software at
> all.
> In fact, I doubt it should.
> The main problem websites solve right now is installation. Its zero
> install
> and people love that.


I'd agree somewhat if you define "installation" broadly enough to encompass
synchronization issues, for e.g., templates, user settings, scripts, and
data.  But if I understand you correctly (and I'm not sure I do), I think
you overlook the market's perceived value in server-side collaboration
solutions using RDBMS back-ends, e.g., the LAMP and WAMP phenomena.

The notion of a "word processor" gets really interesting if you rework its
concepts so that the database goes center stage rather than being an
adjunct. For example, the customary dividing lines between a word processor
and a spreadsheet begin breaking down and it becomes far easier to integrate
financial and text data. Automated document assembly becomes far easier. The
need for template files disappears except as a means to create a model that
could be "learned" by the DBMS for its output, along the lines of schema by
example.

Suddenly, you gain an integrated database of historical documents with rich
metadata that is far more accessible and useful than a mass of individual
word processor files scattered around networks and individual desktops with
only text retrieval search engines and human memory to bridge the data
recycling chasm. And you come up with a solution in which a dead-tree
"document" is only one out of many types of output. E.g., you can really
begin integrating text processing with shared calendaring, contacts, time
and billing records, on and on.

The real problem with modern word processors is that they still are shackled
too much to their predecessor electro-mechanical typewriter paradigm that
had production of dead tree paper documents as its sole objective. Word
processors still ape the old approach that treats typewriter-like paper
document production as primary and everything else as ancillary at best to
that core function. But there is no longer any physical need for the
Roll-A-Dex contacts card index to be separate from the typewriter. They've
both been digitized, but never fully integrated, as they could be in a
database-centric word processor. All seem to agree that that the future is
electronic documents rather than paper, but word processors have never been
redesigned to implement that vision. They remain defined by the typewriter
model.

[more]

Moving any computing to a server ignores open source since no open
> source-office provider is going to have the money for server side
> computing.

This leads to companies or groups of friends having to operate a server with
> this stuff and that effectively makes everything had to install again.


I disagree strongly here. There is no reason why a server side app can't run
on a single computer isolated from others. In fact, I'm using a half-dozen
or more open source web apps on my own system and grant no one else access
to them via a network. But should I choose to, then the new user would have
immediate access not only to the software but also to the data. From my
perspective, that easy extensibility of software and data is an important
advantage of server-side apps. While I would agree that today installing web
apps is typically far more complex than installing client side apps, But I
see that as more an engineering issue than an absolute barrier. I.e., we
need better web app installers.

[more]

What really will stay is communication. People want to have an easy way to
> communicate with each other.  Share docs and all that. I would guess that
> this is the core of your conclusion that things will go server-side.  So I
> really agree with your arguments, just not with your conclusions.
> Things are moving more to Peer2Peer. Everyone is a server and at the same
> time
> nobody is. Here Jabber comes to mind.


I  don't rule out any technology simply because it is located on the client
side. For example, it makes a lot of sense for apps dependent on
user-defined word lists to be located on the client side, e.g., spell
checkers and autotext-like functions should be client-side apps that work
with whatever editing dialog has the operating environment's focus. And I
think that P2P definitely has a role to play. But I also think that a user
shouldn't have to use different UIs to work on a wiki, for example, or a
paper document. And it's that collaborative building of information bases
with Wikipedia perhaps being the penultimate example that I see as being the
critical next step for word processors. Yes, you can kind of do that now via
WebDAV, but OpenDocument seems to me to pave the way for rich server-side
word processors that enable co-editing of documents.

Maybe a concrete example would be of assistance here. Where things are
headed in the legal profession is largely an online electronic experience.
Legal teams work together to assemble documents, then upload them to the
court's server, which automatically serves the other side with a copy. The
other side's legal team constructs a response and uploads its response. The
opposing sides work together to create some documents, then file them with
the court. In the electronic courtroom, transcripts are already done in
real-time and displayed on everyone's monitors. Visual and audio
presentation of documents and other exhibits are made via a courtroom
network node and displayed to everyone, including the jury, on monitors.
Opposing legal teams have ready access to their entire case files including
all documents produced in discovery by each side and with skilled assistants
can retrieve information in a snap of the fingers. When the jury retires to
deliberate, they have instant access to online jury instructions and all
admitted evidence including documents and testimony. Although the door was
opened when judges began holding hearings via telephone, courts are rapidly
embracing video hearings with remote participants. If you're interested in
further detail, there's a good 14-page summary of the state of the art from
the bleeding edge Courtroom 21 Project at <
http://www.legaltechcenter.net/publications/articles/status.pdf>.

Writ large, the processing of lawsuits has been for centuries a
collaboration amongst opposing law firms and court officials to build a
record of all proceedings. It's a process of winnowing information down to a
single document, the judgment.

And that brings me to another step that needs to be overcome in tomorrow's
word processor, the integration of research and writing functions. It's
another area where the typewriter paradigm still rules, where research is
something separate from writing. E.g., having used a top flight text
retrieval search engine (Isys) for some 15 years, I can't imagine going back
to the days when my ability to retrieve information was limited to my memory
and my classification skills. But word processor technology still seems to
rest on the premise that the operating system and word processor reside on
Floppy Drive A and the data resides on Floppy Drive B. The word processor
model simply ignores the fact that when writing, ready access to more
information is better than less.

[more]

The better office mousetrap, then, is one that is not monolithic and is
> flexible enough to be reused in situations where communication is more
> important then being able to produce stunning paper-output.


Agreed, although I'm hopeful that ODF will usher in an era where we can
create online documents that are more richly formatted than HTML and CSS
allow.

I couldn't agree more on the non-monolithic aspect.

[more]

This is exactly what KOffice2 is focussing on. To have a lot better system
> then any other suite out there for integrating office components in other
> office applications. And I'm pretty sure it will not be limited to just
> embedding in office apps. Embedding the text component in email apps or IM
> apps certainly has value as well.
>
> I won't go into details as its too far off topic, but I'm sure you'll be
> happily surprised when KOffice2 comes out and the months that follow where
> people start to build on top of the component model we created.


I'm interested in learning more and maybe in participating. Got a starter
link or two? I feel like there's no alternative to OOo for our project over
the short term because of its feature set, but it's definitely not a
platform we should build on over the longer term.

Best regards,

Marbux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20061016/4acdcca9/attachment-0002.htm