Porting Delphi Clients to the XO
Porting VistA to the OLPC. For introduction to VistA components see VistA Monograph Wiki.
Porting Delphi Clients to the XO
The most essential clients are written in Borland Delphi. Others are written in Java and other programming languages.
There are several approaches to porting the Delphi code to the XO.
- Running under Wine.
- Translating Delphi to Python.
- Translate to Lazarus/Free Pascal.
- Translate to server-side AJAX.
Note: None of these options have been tried nor tested on the XO.
NEED Test Harness to compare response of old Windows based GUI to new replacement on XO.
Wine
The folks porting to Wine say they are almost there. Don't know when it will actually arrive. Don't know if we have the resources to run software in MS Windows emulation on an XO. Nancy is looking at minimum cpu, memory footprints to support CPRS under wine and on real hardware with windows.
DelPy
Our original plan was to create DelPy a Delphi to Python translator. It now looks more likely we will be translating to Lazarus/Free Pascal.
We were looking at using Coco/R an open source tool tool which takes an EBNF grammar with attributes and semantic actions and generates a recursive descent parser and lexical anaylyzer.
Here is a Delphi 6 grammar. It is from a stillborn open source Coco/R project for Delphi. The was a brief flurry of activity in 2002. Nothing has happened since then. There may be copyright/licensing issues since is derived from a BNF grammar published in the Delphi 6 Help file. Stephen is checking his Delphi 6 distribution to see what copyright, license notices are attached. If we use this grammar we will port it to a more modern Coco/R implementation
Here is a Delphi 5 grammar derived from the UCSD Pascal grammar. It is a little farther out of date, and will take a bit more work to put it into the Coco/R tools. The copyright/licensing issues may be easier if we start here.
In the unlikely case that we revive the DelPy project we will use CocoPy a Coco/R implementation in Python by Ron Longo.
Compile with Lazarus/Free Pascal
Not all components in Borland's VCL (Visual Component Library) are available in LCL (Lazarus Component Library). In particular, LCL is missing TFrames and TRichEdit. We will probably discover more gaps that NEED to be filled. We may be able to encourage Larzarus developers to fill thes gaps, or some OLPC developers may have to become Lazarus developers, so we can fill these gaps ourselves.
Here is a chart showing comparing the components available in VCL vs. LCL. We NEED columns indicating components used by VistA front end clients. Don't know how up to date the Delphi and Lazarus columns are.
We may discover issues with the Free Pascal compiler that NEED to be addressed similarly by encouraging or becoming Free Pascal developers.
It may turn out that we will NEED techniques to translate from one Pascal dialect to another similar to the DelPy translator described above. The D6 grammar gets even closer to where we want to start. Hope we can resolve the D6 Help File license issue.
Compile to Server-side AJAX
Only a browser is needed
For some time yet, we need to expect that the existing CPRS (written in Delphi) development will continue, perhaps "forever". So this option is aimed at a "moving target" until it overwhelms the existing efforts.
This idea is very young and the needed analysis has not yet been done to see how feasible it is. If most of the CPRS code is dealing with whacking and diddling "window panes", and has very little logic, then this may be an easier way to advance the state of the CPRS access. Unlike the previous options, there would be an abandonment of the existing CPRS code base (ldl: IMO) since having some automated mechanism to separate the "CPRS" from the "diddling" is probably not feasible.
However (ldl: IMO), once done, the tediousness of maintaining low-level Delphi code is probably overcome by moving the implementation out of "code" and into more of a "specification". (ldl: I doubt that it will ever be an "end user" level activity, but modifying CPRS functionality could and should become a CAC level activity, just like "templates" and other VistA elements).