Pliant talk forum

Pliant talk forum

Discussion: Pliant roadmap

Here is the roadmap I plan for Pliant, for the two next years,
and how Pliant teaching system might ultimately take place.
Message posted by hubert.tonneau on 2003/09/22 13:20:20
Hi heverybody,

At the end of 2005, I'll be 37, and it will be just 25 years since I started
programming. Also this end of 2005 date is resonably matching the date where
I think FullPliant can be a complete system (a complete Windows or GNU replacement)
with both strong server and client side, and the all set of standard applications
a typical end user is using.

So, the roadmap is:

before end 2004: introduce Pliant web protocol and browser, including full
                 multimedia support (*), as the ultimate Pliant user interface
       
before end 2005: introduce Pliant word process or spreadsheet, using Pliant
                 web for read write access to documents, and standard web
                 and PDF for viewing only.

The most important is perhaps that I plan to use Pliant web browser as the
main source to the ultimate Pliant deploying.
What I would like is Pliant web browser multimedia part to enable me to have
online meatings where I can export my screen (Pliant web display) to all
attenders, and have shared sound with all of them, so that I can explain though
talking one part of Pliant, and type, draw or cut paste exemples when required,
so that all attenders see them and the Pliant server is recording the all
multimedia session (screen + sound) so that anybody else interesting with
the subject can later replay the session.

This is a very important decision, because it's the ultimate way I've
selected to share my knowledge about Pliant, so have other people deaply
master Pliant, and it's web oriented, so that the only constains will be:
. have a 64 kbps down stream (in order to attend live). No bandwidth constrain
  to do offline playback.
. run FullPliant in order to get Pliant web multimedia capabilities
Running FullPliant is a serious constrain because:
. Pliant web browser on FullPliant with use the Linux frame buffer as it's
  graphic card interface, so it has to send it RGB encoded frames, whereas
  it's more efficient to send Yuv encoded frames and have the graphic card
  compute the conversion, but it would need X11 XVideo extension, and I don't
  want to rely of X11 for FullPliant ultimate user interface. So you will
  just need a faster process, also I don't know how fast, for the video
  but since Pliant learning talks will not use video, it should not be a
  problem.
. I will try to provide a bootable CD and boot from memory stick for FullPliant
  so that you can run it on an existing computer without installing FullPliant
. Anyway, the standard FullPliant install will require fairly standard
  hardware, I mean a VESA 2 graphic card (including Intel i8xx ones),
  AC 97 compatible sound (Intel i810 audio), a standard IDE disk controler
  or a USB memory stick
. We might get a Pliant web browser with multimedia capabilities running as
  a standard Windows program at a later point, but I have no plan to carry
  it myself.
The online teaching sessions will additionaly require to use a headset with a
microphone connected to the sound card.

When the technical issue is solved, then I plan to assign some of my time to
have online meatings with people asking for deap explainations about various
Pliant parts, constructing a first level of documentation that will be the
raw materials more skilled writters can use for standard courses or books.


(*) Pliant currenly relies on only two external low level libraries, which are
    zlib (compression) and libjpeg (lossy compression for images)
    Pliant web browser will depend on three more low level encoding librairies,
    I mean:
    libdv2 for encoding and decoding DV image and sound
    libmpeg3 for decoding MPEG2 image and sound
    libogg0 for decoding sound
    This set of libraries has been carrefully selected because:
    . each of then only rely of glibc (not a large set of other libraries)
    . the three selected cover most multimedia scenarios, with the exception
      of doing video on very low bandwith (less than 1 Mbits), but since
      pliant web will enable transparent using of proxy extensions, I prefer
      to have a limited set of stable file formats.
    As an exemple, people might prefer DivX for video, but with Pliant web,
    on any browser, it will be possible to have an extension that enables
    to transparently do DivX on the wan, then DivX to DV or even DivX to MPEG2
    on the lan proxy, then MPEG2 or DV on the lan from the proxy to the browser.


I'm very interested with Marcus point of view about all that, but I posted
to Pliant forum rather than directly mailing to him, so that the discution
be open to all others interested with Pliant futur.
Message posted by hubert.tonneau on 2003/09/22 13:46:47
I've forgotten: the huge problem with requirering to run FullPliant in order
to access live a Pliant session, is that you need a 'standard' Internet
connection.
I mean a connection that does not require you a special driver.
In deaper details,
a router is perfect,
an serial RTC modem is probably ok if the command set is simple,
but a lan modem is probably not because requiering PPPoE,
and an USB modem is surely not because requiering a device driver.

So, the problem is that low end broadband connections are packaged with
a low end USB modem rather than a router.
Message posted by mujtaba on 2003/09/26 05:26:46
Here are my thoughts on restraints you believe will be on Full Pliant in the 
future:
Kernel Performance:
       The new 2.6 Linux kernel will feature the infamous low-latencies
       patches, which will speed-up multimedia (especially sound) at the 
       kernel level greatly.
  
Video: I agree, X11 is something I wish was done away with a long time ago.
       However there has been some break-through work being done at 
       directfb.org. They have succesfully got DRI support on the framebuffer,
       for Matrox and Radeon cards. This means they have 2D AND 3D 
       accleration working with Mesa. And you won't need to rely on XVideo to 
       send video in YUV frames. DirectFB does have interfaces for acclerated 
       YUV video also. DirectFB supports 2D accleration on a number of 
       popular video cards.

Audio: The new linux kernel will replace OSS with ALSA! Advanced Linux Sound System
       It will have a greater wealth of drivers to support almost any audio subsystem
       under a common, plugable interface. 

SDL:   (now I'm being shameless)     
       SDL (I believe) has directfb as one of its many target platforms and I know
       that SDL has interfaces for YUV video also. So if for example, the Pliant
       GUI system would draw onto SDL, and generate sound and video through the
       SDL API, you could get acclerated features with DirectX on Windows, directfb 
       on FullPliant, and  of course X11 on Linux. SDL also claims to have fast 
       software-only routines for absent acclerated features (like doing things in VESA). 
       Its also a common API for direct access to keyboard, mouse and joystick devices. 

I wouldn't worry about Full Pliant's future multimedia capablities should it continue to 
stick with the Linux kernel. Bottom line.
Message posted by hubert.tonneau on 2003/09/26 09:00:02
What I'm trying to build is a minimal set of requirements to complete FullPliant
overall project. I'm not excluding anything, just trying to decide what will
come first.

The big problem with interfacing is that each interface is bringing it's own
set of very time consuming troubles, disturbing me from the main line.
Here are a fiew exemples:
. under Windows, I could not find any properly compiled version of zlib (using
  the well established WinAPI calling convention; all of them did use the
  compiler specific convension in some corners, so that at the end I had to
  download the source, and patch to get it properly compiled)
. I tried at some point to compile GhostScript from source (GhostScript has
  been writen as OS independent very early) and GhosScript as a very nice
  feature that enable to embed all it scripts and fonts directly in it's
  executable, so that the executable is enough.
  Yes, but I compiled it under a system with glibc 2.3, and it refused to
  run on a system with glibc 2 (the glibc init code stopped it),
  even if I'm absolutely sure that GhostScript, due to it's highly multiplateforme
  nature, uses only some very very basic features of glibc
. I've recently switched from 'stable' to 'testing' in my Debian embedded
  system, so that I switched from gcc 2.95 to gcc 3.3, and the result is
  that the Pliant tiny executable (it uses nothing except loading another
  DLL) continued to work in the Debian, but stopped to work in the FullPliant
  (it says it cannot load any module).

So, I would like to publish a tiny CD image, a tiny memory stick disk image
and say to people: if you want to experiment FullPliant, just select some
conforming hardware, boot and enjoy.
The advantage of booting on FullPliant is that then the environment is very
well defined.
At the moment, I guess very very fiew people did test FullPliant, because
the install process is very powerfull, but also very complex so that it's
absolutely not suited for installing a single machine.
I need to provide ready to use images.

I'm very interested to learn directfb existence, and it might be the solution
at some point, but reading the  http://www.directfb.org/modules.xml page,
I guess using it would open a large set of ... ir works on some hardware,
not on others.
Moreover, I find very strange they use GTK on top of it, because I personaly
see X11 as a light layer compared to GTK and even more to most GTK based
applications.
On the thechnical side now, I'm very well informed about computers drawing,
and I say all projects fail on the same issue (starting from PostScript,
and including all graphic drivers): they want to implement too many
functions.

This explain why I will probably stick with minimal dependency for the first
intance of the project, then extend. Same I did with Windows.

For Video, if interfacing with the frame buffer, there are only two missing
harware instructions:
. the ability for copy one rectangle (scrolling)
. the ability ot access the screen in Yuv (multimedia)
My personnal point of view is that if Pliant get's popular at some point

For audio, OSS is very very good from my point of view (I have a Pliant
interface with it which is 10 lines of code). As far as I understand it,
ALSA is required only for musician applications, not multimedia applications.
Basically, if you want to record or play, then OSS is just fine. ALSA is
if you want to generate music.

Now for SDL, the question is open. Currenly, I'm using X11 because in
FullPliant, the user interface is currently handled in the emebedded Debian
(I'm using Mozilla). I will switch to frame buffer when switching to
Pliant browser as my main interface.
Also, I may then look at SDL as an optional way to get some hardware
acceleration under FullPliant, and even more, as a way to get cross
plateform multimedia.

In very fiew words, you've convienced me that I have to look at SDL as a
way run run Pliant web browser with multimedia capabilities under Windows.
So, we would end with 3 different configurations:
. direct to Linux kernel and frame buffer (FullPliant with multimedia but no
  hardware acceleration)
. direct to Win32 (Windows without multimedia capabilities)
. through SDL (most advanced, but with potencial interface related troubles)

For interfacing with complex applications, I rather look forward the solution
of implementing VNC client in Pliant browser, so that it will then be possible
to provide a ready to use Debian system as a single .tgz file that you will
unpack in a subdirectory, and since this Debian will not need to access any
hardware part (it will use VNCServer as a screen), it should be completely
hardware independant, could be run as non root, and still run mainstream
monster applications such as Mozilla and OpenOffice that you would access
from Pliant browser. This is a good model for desktop applications,
but excludes multimedia applications because VNC is not suited for these.
The same interface, will be used to access a mainstream box on the network
running Windows mainstream applications.
An emulator could be a better solution since it would enable to run Windows
in the same machine, but here, there seem to be no free solution, and no
simple (they all need durty hack in the kernel) solution at the moment.

The general goal is to provide a simple and stable system for people that
don't care about the operating system, I mean just want to deploy the
application and loose as fiew as possible time in boring issues.

Anyway, I still have two serious problems: 
. The Internet connection is now very often an USB modem, so my initial plan is
  suited for companies because buying a rooter is no problem, but might not be
  for individuals.
. Requiering to run FullPliant just in order to attend an online meeting
  is something too constraining (here you seem to point out that the solution
  is SDL. So let's cross fingers)

Also, I'm now convienced that:
. Pliant is something too new (cleaning up too many parts of existing way of
  proceeding) so that it cannot continue with so fiew talks about it and
  that's why the multimedia part will be part of Pliant browser right from
  the beginning
. Pliant needs the pliant web so that Pliant applications can get a state
  of the art user interface (HTML/HTTP is nice for the low end but does not
  scale, and existing GUI including Windows, GNOME and KDE simply missed
  the point of flexibility)
Message posted by marcus on 2003/09/28 21:51:35
The possibility of video conferencing "in Pliant' is thrilling! Specially in 
academia. The idea of using this tool to learn Pliant directly from
Hubert  is equally great.

My major concern is how would one, with limited knowledge of the technology 
below it, be able to make it work in his/her computer. One can have an idea
of the complexity of the thing by reading the messages exchanged between Hubert
and Mujtaba. Just trying to understand the acronyms already gives one a headache :)

It would be perfect if we can get a volunteer to serve as a guinea pig during
the development of the application. I.e., this person would be in close contact
with Hubert, testing prototypes of the system, presenting suggestions, and 
documenting the whole thing as it evolves. Ideally, this person should be in a 
remote location w.r.t Hubert's, and at the outset, have available a PC with the
 necessary hardware configuration, only. Then, from there, (s)he should get 
the thing working from scratch.

What do you guys think?



Message posted by hubert.tonneau on 2003/09/28 22:03:49
That's why my initial goal will be to publish a bootable CD (and memory stick
image as an alternative).

So, when booting, the system will do most on it's own, checking the harware,
and it will either be very simple to configure, or the system will display
a clear message specifying what part of the hardware is not conforming,
then stop.

Trying to find solutions for non conforming hardware will be the second shot.
Message posted by mujtaba on 2003/09/30 02:21:46
It will be hard to convince people to download and burn a CD image,
just to try out a new kind of language or software(though not as hard 
as convincing people to install Linux). And installing a software 
application is just a step better than that. 

I think Pliant's existing web interface is a very, very good start. For example,
there are already places in the documentation where I can see and execute code
without installing an application. If I could be given lessons through this
interface where I can also edit the code, it would serve as an effective tutorial.
I suggest using Mozilla's Midas, which allows you to make a rich-text editor
embedded in HTML. Just tie in some Javascript with some web buttons, 
and you got your self and online IDE! I plan to have my team work on a similar
idea (no Midas) for the PliGame tutorials.  

http://www.mozilla.org/editor/midas-spec.html

It would be nice if Pliant was written in Java and could dynamically compile
java bytecode. It could then work as an applet, taking .pli files from a
server and generate applet code for the user. Or Pliant could simply generate 
static byte code on the server. Okay don't get nauseous, I have another idea.

I have seen examples where SVG and Javascript were used together to create
GUI widgets such as sliders, textboxes ect. over a standard browser. Pliant
could have modules which wraps all this SVG XML and Javascript code into
widgets, callable by a simple API much like .page. The Pliant http server
could then generate the SVG+Javascript on supported browsers. Or you could
simply use XUL, although its only available on Mozilla and Phoenix.

http://www.kevlindev.com/gui/index.htm
  

Message posted by hubert.tonneau on 2003/09/30 06:17:46
The problem is reliability, and source code size.

All the technologies you site are interesting in some situations, but raise
a large set of reliability problems. Moreover, they suite poorly in the Pliant
goal which is to provide a resonably short code that can do the job, so that in
case of problems or new needs, you can truely review and extend it.

I've investigated advanced Mozilla capabilities (DOM + SVG is something great)
but concluded that in such a case, reimplementing cleanly is easier than
interfacing. The web is a great thing, but the HTTP + HTML + SVG + DOM + javascript
specifications are broken (too complex for carrying the work), and implementations
can hardly be any better than the specifications, so there is very little hope
in this area.

Please notice that there is already a solution in Pliant roadmap for people
that don't want to install any new software, and it is VNC.
There are several VNC clients, and if you want to install none of them, there
is a Java VNC applet.
So, if you don't want to install any Pliant software on the client machine,
then you will connect to the server through VNC, and the server will run the
Pliant browser. Only a bit more bandwidth and horsepower in the server
will be consumed, so it's very very well suited for occasional users.
Message posted by mujtaba on 2003/09/30 15:09:43
Oh, in that case you should take a look at tightvnc. Its the same package,
but its been improved, and optimized for narrow bandwidth. 
http://www.tightvnc.com/intro.html

BTW, VNC is not mentioned in the roadmap, but you do mention that you may
consider making a client to display debian apps through the Pliant browser in a 
later post. Perhaps then you might consider having the Pliant browser itself
rendered through VNC?

Message posted by hubert.tonneau on 2003/09/30 18:55:41
I plan Pliant to support VNC client and server,
so that users with a VNC client (or the VNC java applet) will be abble to
view any application using pliant browser as it's interface,
and it will be possible to embbed VNC sessions in page displayed on the Pliant
browser, in order to remotely access an application on a Linux, Windows or MacOS
box.