Hello all! I am new to Plucker and new to this list. I'm currently working on a project where we are attempting to build a flexible development platform for Palm OS... The components of this platform will be as follows: 1. A SQL database for the Palm that synchronizes with a "real" database server. We have already completed this! It builds another layer on top of the Palm DB structure to allow tables, fields, records, etc and has built in basic SQL support (though no relational queries just yet... as in, no joins... but it does support parameterized queries which we use to implement queries similar to relational in nature). 2. An XML based "scripting" type language that will allow you to generate "forms" based on data in the SQL database. For example: execute a query, iterate through results, and build a table that will be displayed on the Palm screen. We chose XML because it is much simpler to parse, and have already written a SAX style parser in C that weighs in at 139 lines of code (debug compiles to 810 bytes). This does not include the scripting language, as this is what we are developing even as I write this. 3. A "client" API for GETing documents from the "server". It will be client/server on the conceptual level, since the "client" and "server" will both be on the Palm and will use an API to communicate instead of a protocol. When the client requests a document, it will get a processed document (much like requesting a PHP page from a server... what you get is HTML that has been generated from PHP). We have yet to determine what our scripting language will output, but it will most likely be a binary format, as opposed to a text format (such as HTML). 4. A UI component that will render the processed document returned from the server, handle any UI controls, handle POSTing forms, etc.
It is in the area of #4 that Plucker holds great interest to us. From a UI perspective, it appears Plucker has support for images, color, forms, and so on. What we would love to do is use Plucker's rendering engine in our tool. Management is open to the idea of us releasing the Palm side of our work as open source. I have spent about 10 minutes looking over the viewer source, so I don't know how accurate my understanding of it is. Since the viewer seems to work on documents that are already compiled, in a sense, to a binary format, this could be the very format that we have our XML scripting language output. We could then pump the output into Plucker and go. However, it also seems that the code for reading/manipulating the "document" (or Palm DB) is written directly into the rendering code. With this being the case, the only way we could "interface" with the viewer would be to place the output of the scripting engine into a temporary Palm DB. If I'm reading the code right, I think this would force us to copy any supporting images/files into the temporary DB as well, which would hurt performance and memory requirements (since the images would already be located in our SQL database). Our idea would be to abstract the document access out of the viewer engine. The renderer would go through an API to access documents/images/etc. Anyone could "plug in" an implementation of this API. We would then be able to write an implementation that could directly pump the output of our XML script to the renderer and give the renderer direct access to our image data. Is this something anyone else is thinking about or even working on now? Should we discuss it further here, or should we just code away and submit whatever changes we make? Does the plucker project even want such changes, or do we just create our own "fork" of the project? Thanks for your consideration.
