|Pliant talk forum
Discussion: I want to help improve Pliant
Here I will present my thoughts about what is should done to
make Pliant more useful tool, both for me and others.
|Message posted by thomasb on 2004/02/24 17:25:46
|I think it's about time for me to get more involved in the Pliant project.
Somehow I have been hoping to find a more mature/popular programming
language/environment with the same unique properties as in Pliant. LISP is
probably the closest match, but it lacks the property of simpleness (short code
I am programmer, although I have relative little "real world" experience I am
sure I have a lot to contribute to the Pliant project, both in implementation
and documentation, but also in more long term planning.
In the short term what I would like to work with is to improve quality of
HTML-code produced by Pliant. HTML and web is a matter of communication, and
without a common language any communication will not succeed. Fortunately HTML
and CSS is widely supported nowadays (with MS IE as the biggest exception). In
my opinion there is really now excuse today to not follow the these standards.
My goal will therefore be make sure that all HTML code produced by Pliant never
violates the standards as defined by W3C. This does not mean that every single
detail of the standards need to (or should) be supported, but that what is
supported should be done right and for the right reason.
To reach this goal, we clearly need a very powerful tool. Pliant is already very
powerful, but I am not to happy with the current "page-format". Therefore I
would like to start with some present some of my thoughts about what I consider
is important for such a format. One aspect of any language is its syntax. I do
like Pliant's default syntax as programming language. However used as a markup
language I am not so sure of its usability. A good markup language must
introduce as little overhead as possible, be robust, simple and easy to use.
Other formats like XML has very few of these properties, the page-format have
some, but lacks bit in robustness and ease of use (eg. the use of [ ] for
multiline text is a bit awkward). I will propose to use a markup language called
Enamel. Since I don't expect anyone to ever heard about this language I will
provide a detailed description of it in a separate post.
The semantics is an other important aspect of a language. There are several ways
to group languages by semantics. Declarative languages are passive and used to
describe facts. HTML are such a language. The other group is active languages,
which include most programming languages. I quite sure a declarative language is
best suited for documentation purposes, since it makes it much easier to adapt
the same information to different medias. It is also important that the language
only defines the structure of the information, not presentation. Construction of
such languages requires good knowledge about the domain of the problem.
Fortunately documentation is not a new problem, there exists several languages
for the purpose, eg. DOCBOOK and XHTML. I would be stupid to not look at these
languages when designing a new, but I would also be stupid to implement a
feature just because it exists in an exiting format. Every feature should have a
good reason the be implemented.
Any comments are welcome.
Med vennlig hilsen
|Message posted by hubert.tonneau on 2004/02/24 18:04:24
|It's hard to talk about Pliant document design at the moment because most of it
is already settled in my head, but there is no code or introduction document yet,
and I still have several details to fix.
Basically, Pliant is 3 stages:
The bitmap library is already very strong, and will only be refined now.
The vector library is mostly settled, but needs industrial testing, and might
still have some interface changes in the futur.
The XML rendering engine interface is mostly fixed, but it's implementation
still lacks many details.
Also one point is very clear yet:
the rendering of an XML subtree must be fully defined by the subtree content
+ the set of parent nodes up to the tree root which stands as it's
environment, nothing else.
So CSS is just a joke until you translate it to a document surrounding tree.
Pliant HTTP server styling has already been redesigned in order to fit this
model, with high efficiency contrain as a bonus, so it will not change anymore.
Environment is carried though the 'TagStack' data type implemented in module
and each XML tag HTML rendering is implemented as a 'tag_html' or a couple
of 'tag_html_open' and 'tag_html_close' blocs.
The next release of Pliant will contain the /pliant/graphic/browser/ tree
demonstrating XML to vector rendering.
The huges advantages of Pliant documents handling are:
. all the 3 stages (XML, vector, bitmap are exposed). Any standard (read all)
that want to expose only one of the three stages is just a piece of crap.
. the vector language contains only 5 very carrefully selected drawing
instructions, which makes it much much simple so much more reliable, yet
basically as powerfull has PostScript or PDF
. the vector language contains a powerfull (high resolution) bitmap drawing
instruction so it will not need endless extensions as PostScript or others
The objective of Pliant is absolutely not to conforme to the HTTP + HTML + SVG
prepose a much much MUCH simple one that basically works.
Then the Pliant browser will provide a sample implementation, and we will
provide several 'do with existing systems' solution such as XML -> HTML,
server side rendering, VNC server, and possibly others.
|Message posted by thomasb on 2004/02/24 20:00:24
|> The objective of Pliant is absolutely not to conforme to the HTTP + HTML + SVG
> prepose a much much MUCH simple one that basically works.
I agree, but like it or not this is the standard. Pliant will never become a
usefull tool if it does not support the current standards, at least to some
degree. The fact is that most webpages HTML + CSS will be sufficient and not at
all complex. More advanced web-applications however, will need heavy use of
clearly be better choice.
As an example. If I develop a webshop using Pliant, which requires my customers
to download the Pliant browser to able to shop, I will not get many customers.
At least the basic must be accessable through a standard browser.
> Then the Pliant browser will provide a sample implementation, and we will
> provide several 'do with existing systems' solution such as XML -> HTML,
> server side rendering, VNC server, and possibly others.
Server side rendering should only be used as the last resort. Most of the time
the exact layout is not very important. What's important is the information
(text). Again, I am now taking about documents and simple applications.
For more advanced application we need a modern remote desktop protocol. X is
quite useless. RDP is too simple. A good desktop procol should be scaleable and
complete. Every aspect of the desktop should be supported in an consistent
matter including screen, input devices, sound, printing, scanning, storage, etc.
An implementation does not have to support all, and it should be up to user to
decide where a task should be done. If I would like to run a videoplayer on a
remote computer, I might want all decoding to be done at the server if the
client is weak. However if the client has some hardware capable of YUV to RGB
convertions, it would be most reasonable that YUV to RGB is done by the client,
saving network bandwidth. In some other situation it I might want the client to