Pliant talk forum

Pliant talk forum

Discussion: Using java to add VNC like control to the Pliant ui HTTP proxy

Rectangular controls that communicate to a vnc server
can be combined with other html controls to provide and
overall full featured interface to pliant ui.
Message posted by maybe Boris Reitman on 2006/01/25 18:16:32
The java applet VNC viewer supports canvas size configuration.
The pliant ui http server proxy needs to sends html code to embed
a vnc viewer applet with correct parameters (server address + bounding rectangle),
for all controls that can not be rentered using plain html tags.
Message posted by hubert.tonneau on 2006/01/25 19:03:35
It is not yet clear to me what the usability boundaries of the HTTP proxy
will be. I mean, if you look at pliant-96pre13.tgz, the code start to be
resonably correct for a database usage.

Also several areas are still to be studied and devellop:
. sending images smartly (by smartly I mean that we change the image URL
  if and only if it's content chanaged in the ui client, so that the web
  browser cache applies)
. resending part of the tree using DOM innerHTML

Assuming that we have some server side rendered areas:
. we can easily catch (throuh javascript) a mouse clic, and send it to the
. if we have a smart images cache, and since we already have smart scrolling,
  resending the all page is expensive, but not that much since only text
  parts will be reloaded
. if futhermore we use innerHTML to resend only parts of the tree that changed,
  we might end with something resonably usable

If all this works, we might get extra usability up to the ability to have
the mouseover feature of the browser work with the HTTP proxy, and maybe
threads (time displayed in the test page).

Also, in this Javascript DOM scenario, we have client side scrolling only:
the web browser is receiving the all document content. It's good for some
applications but can be very bad for others.

Now, with a Java VNC protocol, we get two more bonus:
. the protocol might be even lighter than AJAX
. we can have either client side or server side scrolling
 (through 'copyarea' / 'bitblit' instruction)

So, it's not clear to me at the moment what exact extra usability we get
with Java, the downside beeing that assuming a working Java on the web
browser is even more hasardous than assuming a working Javascript.

On my side, I will continue to explore Javascript DOM possibilities and
improve the Pliant ui client HTTP proxy.

On your side, what do you need to be abble to explore the Java possibilities ?
Message posted by maybe Boris Reitman on 2006/01/26 15:18:44
I will start with implementing a VNC server in pliant 
by implementing the RFB commands. And prepare a little test.
But I would need you help later on to put it inside the layout/console framework.
Message posted by hubert.tonneau on 2006/01/26 15:36:30
Please notice that there is already a VNC client implemented in Pliant (I
don't know if it still truely works) so it might help you (the auth part for
It's in /pliant/protocol/vnc/

The question I have is:
Why do you want to implement VNC server protocol in Pliant and reuse
VNC client java implementation rather than picking the VNC java implementation
and changing it to make it match as closely as possible the contrains to
work with the Pliant HTTP proxy ?
Message posted by maybe Boris Reitman on 2006/01/26 16:11:10
http proxy now sends html commands like <b>some text</b>.  Are you suggesting 
to use ajax to render this text, or everything to be done by one java applet ?

i think along these lines: the pliant http proxy must decide that a certain layout subtree 
can not be rendered with ajax, and therefore send html code
<APPLET CODE=VncViewer.class ARCHIVE=VncViewer.jar WIDTH=$x HEIGHT=$y>
<param name=PORT value=5900></applet>
for this subtree, and instead of render_html call a function render_vnc
for it. If a server replays this layout subtree, the proxy calls render_vnc 
Message posted by hubert.tonneau on 2006/01/27 12:41:18
Here are the plans - with no garantie of achievement - :

The HTTP proxy will be responsible to decide what must be rendered by the
HTTP proxy.
It will be possible to force the decision at application level when the
default behaviour is no good.

Now, the HTTP proxy has two solutions for these area:
. send a PNG or JPEG, use AJAX to send back events, and redraw all the area
  each time a change is required
. use a VNC like protocol to connect with a web browser java applet.

The second solution has two advantages:
. can use bitblit/copyarea and can redraw only part of the area
. maybe ability to catch more events
And two drawbacks:
. compression is more customisable so more complex to provide
. a working java is not always available on the web browser

Also on the contribution side, I will write all the AJAX based interface,
and let you or somebody else write the Java version.
I will provide full support to the HTTP proxy engine internals to the
Message posted by maybe Boris Reitman on 2006/01/28 05:48:12
Ok, I understand what you mean.  I have started with a working vnc java applet
and began to remove all the un-needed code from it.
Message posted by hubert.tonneau on 2006/01/28 12:03:03
Can you send me the Java code you start from, just to give me an idea of the
general layout.

Also the most difficult point might be to decide what compression scheme we
use to send the rectangle to be refreshed to the Java applet.
Message posted by maybe Boris Reitman on 2006/01/28 16:59:24
Ok, I emailed you.  The java applet supports all encodings found in VNC protocol.

Also, another note, java can access javascript and manipulate DOM of the 
hosting web-browser. And vice versa, javascript can call Java functions. 
If the HTTP request object is not good/slow because of 
the connection time for an HTTP protocol, a 1-pixel applet can provide a 
constant tcp link between web-browser and ui client http_proxy. This artile
shows how, but it might be an old one,

Message posted by hubert.tonneau on 2006/01/28 17:58:09
According to me, the overhead of the HTTP protocol is negligeable when
using keep alive connections.

What is missing with javascript is the ability to do bitblit/copyarea
on an image, and to reload part of an existing image, so smart redrawing
would require to cut the single large image into several smaller one, and
use absolute positioning to move these around an reload only some of them.

A minimal java interface is probably valuable if it can provide this
Also the complete Java applet derived from VNC is probably a good solution,
we might be abble to strip it down to:

Assuming that some part of the Pliant ui client tree is rendered as a bitmap
on the web browser side, and the 'img' HTML tag containing the image as ID

. What is the minimal Java applet to perform 'copyarea' in the 'foo' image.
  I mean copy area x0 y0 x1 y1 of the image to x y x+(x1-x0) y+(y1-y0)

. What is the minima Java applet to get a new bitmap loaded, then have
  it bitblit/copy to x y in the existing 'foo' image

Pleas notice that it is just rough idea, not at all a request to do things
that way.
Basically, from my point of view, the smaller the Java code is, the better
it is.

Also, if we can settle things that way, the key advantage is that the Java
is just an extension to the AJAX mechanism providing more efficient redraw
through the ability to use 'copyarea' and reload only select part of the
image instead of reloading everything each time.
Message posted by maybe Boris Reitman on 2006/01/29 10:49:46
Not sure if access from java to the browser allows more than javascript can do.
But I found this:

As per the java applet (if we are going to still use them)
since we could have several java applets on a page,
they need to identify themselves.  I suggest that upon the connection,
they will say a greeting message with their ID.  
Their ID would be configurable through an option 

<APPLET CODE=VncViewer.class ARCHIVE=VncViewer.jar WIDTH=800 HEIGHT=632>

<param name=PORT value=9876>

<param name=ID value=23495834857>

Message posted by hubert.tonneau on 2006/01/29 12:03:34
From my point of view (or lack of knowledge), the missing instruction in
Javascript is copyarea (also sometime called bitblt).
I mean, copy a rectangle part of an image to another position in the same on
another image.
I believe it is possible in Java, but not in Javascript.
If we find a way to do that in Javascript, then we might do without Java.
Message posted by maybe Boris Reitman on 2006/01/29 22:01:15
Ok, looks like the java applet does everything that we need, I sent you all the code.

The ID parameter in the <APPLET ...><option NAME=ID VALUE="any_string_goes_here">... </APPLET>
is sent upon a connection, and can be used to distinguish the applets.
The sample server.pli also shows how all the mouse and keyboard events are
received, and how the copy rect and raw rectangle commands can be sent. 

<APPLET CODE=VncViewer.class ARCHIVE=VncViewer.jar
        WIDTH=300 HEIGHT=300>
<param name=PORT value=9876>
<param name=ID value="061H44LAifgcPZYdV2nlmRn60Dl4g/1394857">
<APPLET CODE=VncViewer.class ARCHIVE=VncViewer.jar
        WIDTH=300 HEIGHT=300>
<param name=PORT value=9876>
<param name=ID value="hn392898457cPZYdV2nlmRn60Deut/3345682">

A note: the server needs to describe dimensions of each applet, 
once in <applet> html tag and again upon the connection.

From the server.pli that I sent you, notice the 
initialize_connection s 300 300

method vnc_like service s
  arg_rw VNCLikeServer vnc_like ; arg_rw Stream s
  (var TraceSession log) bind vnc_like_trace
  log trace "VNC_Like connection start at " datetime " from " (s query "remote_ip_address")

  part dialog
    var Str secret_and_id := s readline
    initialize_connection s 300 300
    send_example_rectangle_commands s

Let me know if you need anything else in order to hook it into the code.
Message posted by hubert.tonneau on 2006/01/29 22:17:10
The only problem I have is that you stopped stripping down the VNC applet
at a wrong place from my point of view:
. we don't use anymore the stock VNC Applet so will have to maintain the code
. it's not significantly simpler than the original

So your code shows me that it's a valuable solution, can be achieved with
moderate effort, can be used to ui client side render selected parts of the
page which is better than full page ui client rendering, but the maintening cost
of the code you show me would be too high for me, so we have either to move back
to use the standard VNC applet, or seriouly strip it down to a single less than
1000 lines .java file.

What I would like best is you to just pick ideas from VNC, and rewrite from
scatch the minimal possible single standalone Java applet.
Message posted by hubert.tonneau on 2006/01/29 22:18:54
Please, can you elaborate on what you changed from the original VNC Java code
to get it a working solution for what we plan ?
Message posted by maybe Boris Reitman on 2006/01/30 05:50:11

I have removed code for a pannel with buttons, and code for session recording
(into a framebuffer file that can be used later for playback).
I could strip code for options a bit more, since the code for the gui options
panel is still there, but i left it to initialize default values only.

I have added an additional message during initialization: applet sending
a unique id string to identify itself to the server.

In the latest version, I haven't sent it to you yet, I removed the need 
for the server to send framebuffer size.

In order for me to strip the code more, can you tell me, which encodings do you want
to keep, in addition to the raw encoding (raw is sending the pixels without any
compression).  The encodings are described here:

Perhaps we should keep the ZRLE encoding (Zlib Run-Length Encoding)


Message posted by maybe Boris Reitman on 2006/01/30 09:34:02
Note: The code also has implementation for Tight encoding, not sure what is the spec for it,
but it uses jpeg compression.

I stripped the code some more,
boris@voronoi:~/public_html/vnc_like_client$ wc -l *java
 2644 total

I should be able to strip more, if we settle on what encodings we are going and
not going to use.

Are we going to support mouse shape updates ?
Message posted by hubert.tonneau on 2006/01/30 11:50:26
From my point of view, there are basically two interesting encodings:
. pack5

The 'pack4' encoding is an improvement over RLE, with four codes:
. 00xxxxxx n diffent (n pixels coming next)
. 01xxxxxx n same (1 pixel coming next)
. 10xxxxxx n copy previous (ie copy top)
. 11xxxxxx n alternate
See /pliant/pliant/util/encoding/pack4.pli for extra details.

Now, 'pack5' would be an extension of 'pack4' where we not only provide the
content of the previous line, but also the previous content of the same line.

I have no serious arguments to compare 'pack4' (either through providing the
pointer to the previous line or to the previous content of the same line)
with the VNC initial 'CoRRE' or 'hextile' encoding

Please notice that pack4 can be stacked with zlib, just like RLE.
Basically, it's design to be very very fast, and compress trivial cases only
just like RLE.

What you have to provide depends on your personal taste.
The first question would be: do you have time to make quality comparison
experiments (speed and result) ?
Then you can select one, and keep just one speedy looseless encoding + JPEG
Message posted by maybe Boris Reitman on 2006/01/30 15:07:44
I am limited by time this week, but I can do it next week.
In order to create such comparison, does it mean that I need
to implement in pliant each existing VNC encoding scheme, first ?

Also, I think that such comparison should be made on a real application,
that is, once you hook in the code.  So I suggest to write everything using
raw rectangle encoding, but in a way that allows to substitute the
 encoding easilly in order to compare quality and speed.

In any case, am I removing the code for mouse shape updates ?
Message posted by hubert.tonneau on 2006/01/30 15:12:22
> In any case, am I removing the code for mouse shape updates ?

What I prefer is remove everything, start from scratch, and add functionality
one after the other at a later point.
You may start with no compression at all.
Having just a minimal framework is top valuable from my point of view.
Message posted by maybe Boris Reitman on 2006/01/30 17:47:17
Ok, I will work on it. For now, I put the latest code here:
Message posted by maybe Boris Reitman on 2006/02/04 19:56:20
I have uploaded a more stripped version, at the same url.  
It is 740 lines in total, I should be able to strip a bit more.

boris@voronoi:~/public_html/vnc_like_client$ wc -l *java
  740 total

Message posted by maybe Boris Reitman on 2006/02/08 16:28:15
I have uploaded the next version (02.09) to the same url.

borisr@erdos:~/tmp/vnc_like_client$ wc -l *java
  610 total

I will not have time until Feb 15 to work on comparing different 
compression methods and adding them to the applet. If anyone wants 
to take over at this point, they are welcome.

Message posted by hubert.tonneau on 2006/02/08 21:48:57
Many thanks for this contribution.
Also please dont get upset if your code gets stalled for inclusion for serveral
weeks: so many things worked great for the last two weeks that I'm completely
overflowed with things to finish, and moreover I have no working Java
environment at the moment, nor recent experience using it.

Also, what you produced made the overall picture for the UI client HTTP proxy
perfectly clear, and that's probably the most important.
I mean, there will be three possible ways to access an application written
using the UI server API as it's user interface:
1) A high end standard Web browser with AJAX Javascript
2) A high end standard Web browser with your Java applet
3) The Pliant UI client

I will finish the AJAX Javascript at some point, and it will solve many of
the issues you need to get the Java version work, because it's basically the
same: the Pliant UI client, which is also the HTTP proxy, has to do server
side rendering for some parts.
When it's done, we'll have to talk together again to see how your code
is to be integrated as a more efficient AJAX Javascript alternative.
Message posted by hubert.tonneau on 2006/02/20 18:28:45
Pliant 96 pre release 37 implements hextile in the VNC client applet,
and a mechanism to compare it with Pliant pack4 compression.

On the fiew tests I did, the pack4 encoded flow of datas size was between 95%
and 120% of the hextile encoded flow of datas size.
The hextile encoded flow of datas size was roughly 2% of the uncompressed flow
of datas size.

So my conclusion is that Pliant pack4 and VNC hextile are basically equivalent
as a mater of compression efficiency on low resolution images.
I have no speed comparison.