|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
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
. 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
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,
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
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
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
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
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
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
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
. 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
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
. 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
. 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
. 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,
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
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.
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.
GUI widgets such as sliders, textboxes ect. over a standard browser. Pliant
widgets, callable by a simple API much like .page. The Pliant http server
simply use XUL, although its only available on Mozilla and Phoenix.
|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
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.
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