Pliant talk forum

Pliant talk forum

Discussion: Pliant HTTP server roadmap

Here is an attempt to clarify where the Pliant HTTP is going,
why new extensions are getting in whereas others dont.
Message posted by hubert.tonneau on 2002/08/13 12:57:07
The objective is to enable full document editing using Pliant. I mean the
document is stored on a Pliant server, and edited remotely through a web
browser. This will ultimately cover text documents, extended tables (I mean
spreadsheets) and graphics (both free vector drawing and diagrams drawing).

This raises quite a fiew problems:
. the HTML is not enough for rendering complex things, and the only known
  reliable workaround is to replace complex parts with bitmaps.
. events handling in browsers is weak for doing basic things such as select
  a part of a sentence and send the selected part to the server.
. efficient update of the document (I mean not resend everything just because
  only a fiew lines have changed) is handled in HTML/HTTP through DOM, but
  it's a design mad framework since it relies on Javascript (client side)
  rather than HTTP (server side) in order to apply the changes to the document.

As a result, Pliant, through the Pliant browser, which is basically the same
thing, is starting to implement server side rendering, I mean converting
some HTML with extensions to bitmaps.

Then, when in editing mode, the document would be sent to the browser as a set
of bitmaps (one per paragraph) so that the browser will be abble to send back
a bitmap selection (x,y of the top left and bottom right selected area) to the
server, and the server will translate it to effective selection (it can do it
since it did the rendering so knows every character exact position); then the
server will send back the document, reusing the same images names for the
paragraphs that have not changed.
The idea is to extensively use popup windows (or frames) when some change
is requested to the document in order to reduce the number of redrawings of
the overall document.
Not a panacea user interface, but something that would not require the end
user to have any special software to apply changes to a document.

What's is also still under design is how to properly define the XML tags:
I mean for a given tag, there should be a single place describing how it
translates to HTML, what options it can have, and the dialog that enables
end user to modify these options, so that it then get's very easy for an
advanced end user to create his own set of tags with proper editing dialogs
and rendereing.
Message posted by michel on 2002/08/19 14:35:02
I think that there are two diferent, but linked, problems and two different uses.
First : the choice of the interface and there are a lot of solutions but no perfect one.
Second : the transmission protocol, you want pratically a character by character or pixel by pixel interactivity,
and Html is not done for.
If we realy need that, we have to use protocol as Telnet or similar.
Am I in the scope or have I not understood the problem ?
Message posted by maybe Hubert Tonneau on 2002/08/19 14:53:46
> First : the choice of the interface and there are a lot of solutions but no
> perfect one.

Also the strong position of Pliant is: viewing the document and applying a
small set of changes must be possible through a browser.
The standard browser (Mozilla) will enable it, but will probably be not
very user friendly (too much reload then redraw), and the Pliant browser
will solve the very poor design about all high end browers (the fact that DOM
is linked to client side through Javascript or other languages whereas it
should be linked to server side through HTTP extensions).

This is why I see all concurrent projects (Kword, Abiword and others)
as twenty years late in the concepts. They try to provide an application
that you can download an execute locally, or remotely on a local server,
but what we need is to provide servers that can store documents and enable
end users to modify these remotely through a browser. If the server is
upgrading to a new version, no need to change the client side. That's what
we really need.
In other words, we don't need open file formats for the document, we need
open servers servicing documents, each server providing the right set of
viewing and editing tools dedicated to the kind of documents it stores.

> Second : the transmission protocol, you want pratically a character by character > or pixel by pixel interactivity,
> and Html is not done for.

PNG and JPEG was.

In facts we want to send bitmaps only in two situations:
. editing mode, so that when we receive the selection or clic from the
  browser, we know exactly what it applies to.
. wisywing mode.

This does not mean at all that we will use bitmaps for everything: as a
example, people reading the documentation will receive plain HTML. Only
illustrations (and maybe titles if we want to use nice looking unusual fonts)
will be translated to bitmaps by the server (because SVG is not a usable

> If we realy need that, we have to use protocol as Telnet or similar.
> Am I in the scope or have I not understood the problem ?

We don't care about character mode: we want nice looking wisywing, so telnet
is of no help. What is close to what we want is VNC. It's really close in
facts, but we also want to have an overlay so that erasing popup menus be
Message posted by michel on 2002/08/20 09:09:08
Yes I also thought to VNC but, I think that it is slow and its secutity is not a model.
Perhaps you know how to solve these problems.
Imagine we use VNC the problem wil be only a local problem. 
I think that drawing and photo displays are solved.
There is an other type of problems for editing :
you can only edit that you receive and with a dynamic page or a passive '.page',
you only receive HTML anf if you edit HTML, I do not see how editing the true source.
It is worse for the hiden fields.
I have open a "http://localhost/mypage.html" with OpenOffice wysivig web editor, 
if I ask for the code, I get the HTML code and not the Pliant one.

Message posted by maybe Hubert Tonneau on 2002/08/20 20:58:22
Once again, you are thinking the old way: download the document, make the changes
locally, then upload back. That's not at all what I plan.

When you view a document, and have editing rights on the document, the server
would display a small 'edit' button. When you clic on it, you receive a new
view of the document intended for editing, I mean that if you select some
part, some javascript code will catch the event, send it to the server and
the sever will request your brower to open a popup window where you can
specify the kind of changes you want.
In edit mode, some icons would also probably be displayed on the side of the
document so that you can select the operation you want to do on the document.

In very fiew words, the browser does not need to have HTML editing capabilities.
All we require from it is be abble to render HTML, images, and be abble to
send events back to the server so that the document can be changed on the
server side.
Message posted by thomasb on 2002/08/21 00:22:46
I think a VNC like solution may be the easiest way to go. I write VNC like because
I agree that the currenc VNC protocol i not good enough. As Michel writes the 
securety is too weak (only a password) and it is a bit to slow. The securety 
problem can be solved by using the Pliant secured proxy. 

The speed problem is bit more difficult. I will help to send the data throu a zlib 
compressed tunnel (could be done by the Pliant secured proxy). Extending the 
protocol would probarly be better. This exension could be done in a backwards 
compatible manner so that a standard vnc viewer can be used. The extension could 
be overlay (as Hubert notes), local buffering of images, better compression (eg. 
png) and maybe a local mouse pointer and blinking cursor. 

Hopefully this would make it almost as fast as telnet (by buffering most used 
fonts locally as images), but with full graphic capabilities. Unfortunately a 
special viewer application is needed, but the HTML solution may not be any better, 
since it will only work with a few browsers.