Hi Phil,

Thanks for your comments, I wasn't certain how verbose the initial
proposal was supposed to be so we left out the details from the
usecases.

In order to keep this thread in one list (it's starting to confuse
Gmail a bit) we could continue this conversation in discuss for now.
I have Bcc'd the other lists (including 2d following Mark's use) to
let everyone on those lists know to check discuss for followups:
 Bcc: [EMAIL PROTECTED]
 Bcc: [email protected]
 Bcc: [EMAIL PROTECTED]
As the discussion moves on we can move it to the one group that seems
most appropriate.

On 23/05/07, Phil Race <[EMAIL PROTECTED]> wrote:
I don't follow what this has to do with Swing. 2D would be more affected ..
Swing is ignorant of whether the Motif or X toolkit is specified
and even works with the headless toolkit.

Agreed, Swing shouldn't use knowledge of the underlying
implementation. The reasoning behind including Swing in the discussion
is the SwingAWT work by Roman Kennke. In his project, he implemented
AWT peers using Swing [1]. Now, whether the Swing implementation is
native is another topic of discussion :-)

Also the existing toolkits can still leverage all of the
same internal 2D native code for rendering. I don't see where
you are going to get that from unless if its going to be
a pure Java solution.

I think here we tried to show that the example implementation would be
written in pure Java, with extension points to break to native code as
needed:

"This example implementation will prefer pure-Java solutions, with
public extension points available to enter native resources as
necessary."

Starting with pure Java means we have a baseline that is easier to
understand than one that jumps back and forth to native code, this
also incidentally makes it an ideal example for those wishing to write
their own set of peers. It's a given that without those jumps certain
optimisations aren't practical to implement, but that's why we'd like
to do this in the open so those situations can be discussed and
planned for.


Before going on to a few usecases, I'd like to mention that I already
have a fair amount of code in support of this proof of concept, including
providers for raw linux fb, VNC and (as of 2 hours ago, thanks Guillaume!)
a pure Java X11 provider; there is also embryonic work on an SDL provider
to ensure we cover as many platforms as possible.

> Examples of usage include: implementation debugging, device
> emulation, multiple-head clone outputs/inputs, simultaneous
> multiple-peer output, etc.

Example usecases:

1) Implementation debugging is one that is fairly simple to explain,
  it becomes a tool for us to track down AWT/Swing issues by excluding
  native resources as a possible error source. (Yes it introduces
  another factor, but at least it's independent). This also allows for
  some device emulation, screen sizes, pixel encoding, etc.

2) Realtime output/input on a device (say an N800 [2]) with
  simultaneous output/input of the exact same screen contents on an
  attached PC. This is in effect multiplexing two different devices onto
  a single Java stack. Control of the device from the PC. Useful when
  your touchscreen driver isn't written yet.

3) Distributed remote software agents exposing a VNC or X11 capable
  UI. Easier to secure and to use than a fullblown VNC or X11 server on
  a dedicated host. Easier to deploy too. This is in effect a
  kernel+jvm+libc on any hardware. Including headless ones like a
  router.

4) Point of Sale, The network is the machine, etc... lightweight PXE
  images booting a rich Swing UI direct to their framebuffer. Small PXE
  image, few external dependencies. For bonus points, let the client
  decide which provider to load from a Jini cloud depending on need.

5) Multicast a single UI via VNC, kiosk-type advertising or
  interaction: one window per terminal.

Please let me know if I've left a few out.

Thanks,
Steph

[1] awtswing, http://kennke.org/~roman/swing-based-awt.png
[2] N800, http://www.nseries.com/n800
[3] Maemo, http://maemo.org/

--
================================================================
Steph Meslin-Weber,    [EMAIL PROTECTED]
================================================================

Reply via email to