Hi Everybody, I have a subversion server set up for Neo-PicoGUI. It's linked to on picogui.org. No actual code there yet, but I've been laying out the directory structure and putting in some documentation.
I've been working more on the design for the object model Neo-PicoGUI will use. Thanks to the great suggestions from Nathaniel (njs on IRC) I've researched using capabilities as a security model. The short explanation- there is no concept of user or process security like in a traditional system, just objects which grant particular capabilities. Everything hinges on objects using ID numbers that are unguessable, so in order to access an object you must obtain a reference to it. E is a spiffy language that's completely capability based. There's a good bit of documentation on it here: http://www.skyhunter.com/marcs/ewalnut.html The object model will handle memory management, security, and data types- it will be a library linked with all PicoGUI modules. This will include all pgserver components (only one copy of the library per process of course) and the C client library. Other client libraries should probably choose to reimplement the object model using their language's native OOP terminilogies. This library will probably be called libpok. (PicoGUI Object Kernel) It will borrow ideas from Python's C API and from E. Every object will have: - A reference count - A type, which could be a user-defined type or a custom type - Optionally, a capability - A pointer to type-specific data - A pointer to instance-specific data In objects that are used only within a single process, the capability is unnecessary. The capability will normally be fairly large- 128 bits is common. This is necessary to ensure they're unguessable. Within one process, this is irrelevant. Separate pointers to type- and instance-specific data allows a very cheap implementation of 'facets', which allow different levels of access to the same data. For example, an application could allow another to embed itself within the first by creating a facet of a widget that only allows attaching other widgets inside, and passing on a reference to that facet. The facet would only consist of the object structure itself, a capability, and new type-specific data. This structure would allow pretty much arbitrary data to be stored in the object kernel. Applications could store their own data in the kernel, so that if the kernel is equipped with facilities for storing persistent data or synchronizing to other kernels, the apps would benefit from them as well. Just some ideas- after I do some homework, research this some more, and stop being indecisive about the directory tree I might actually do some code ;) --Micah -- Only you can prevent creeping featurism! ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
