Lets see how to port a conventional word processor, such as Microsoft Word, to Keykos.
Some worry that objects will not be extractable from a through going persistent capability system.
A simple port will not gain some of the capability advantages but a simple port will retain extractability.
We will evolve the ported application and see how loss of extractability arrises.
The Straight Port
We assume here a word processor that exports files that are portable across platforms, to be accessed mainly by the same application ported to the other platforms.
A word processor needs access to a “file” in which to keep the state of a document.
The WP must also have and output port to a window.
I will assume that the data across this interface is on the level of SVG or .pdf and is independent of pixel size and shape.
The recipient of this stream may indeed be proprietary but its state will not extracted as the new platform may have different shape pixels.
The WP will also receive an input stream from the keyboard and mouse.
The mouse coordinates will be commensurate with those of the window.
Other input to the WP is window size and changes therein.
This picture is incomplete but lets pause to consider it.
It represents elements active during display and editing of the document.
It omits elements active during document export and import.
The pink stuff is loyal to the user and the green stuff to the application builder.
Each element of the diagram is one Keykos object and one such object per WP document.
There are one or more domains per object.
The arrows indicate flow of signals as mediated by capabilities.
Separating the renderer from the main WP is not vital but might prevent window occlusion information from leaking into the exported segment.
I draw this separation mainly to show that I can.
Not even WP may know the pixel shape.
WP learns the dynamic window size from the window manager.
In this configuration WP can easily produce the export bits merely by providing a copy of the bits in the segment between transactions.
Importing is about the same.
This model is silent, so far, regarding classic WP logic open document logic.
Such an event is what would normally create the renderer.
If we are to forcibly keep WP from seeing the pixels, the application installation process will endow WP with a renderer factory whose .program is application code that learns the pixel shape and adapts without being able to repatriate the information.
I will assume here that the open logic is once per new document and that the renderer persists.
I wonder what happens when I run MS Word on a Mac (which does sub-pixel decimation: “ClearText”) and I drag a window so that it spans an LCD display and a CRT.
It seems clear that export a conventional WP document is no problem when we take relatively little advantage of the architecture.
Note that we gain virus the protection we spend so much time talking about.
We retain interoperability with the same application on other platforms.
The Clip Board