[gold-devel] What do we want to provide?

Nathan Ladd nathanladd at gmail.com
Thu Oct 20 10:20:25 EDT 2005


>
> As far as userland functionality above the kernel, I do not think I'm
> too qualified to speak on this. For kernel services, I will TELL you
> as much as I can here.


I personally don't think there should be too tall a stack between LSD and
userland.

 Justin, you came up with those classes, I just posted. Why not flesh
> out their purpose, and entry points, and such? At least all that you
> can think of.


I think this begs one of the biggest reasons I want to see Gold run on LSD:
we don't have to just flesh out documentation, but we can concurrently write
code snippets using the classes in System, so we have a better idea of how
we would best use them. Big companies spend big bucks doing usability
testing for APIs, so I think we need to do the same; start writing code
using the APIs. At first, it could be simple test procedures, and the
default 'make test' target would just run LSD and then these test
procedures. Later on, it could be a simple interface.

I like the idea of the text input system also being driven by Golem; but
what are the chances Golem can be done by goldv1?

I think this point has been discussed enough, so I won't go any further. As
soon as I have FBSD 6 installed, my primary goal will be implementing the
'make test' target. Haven't checked the makefile sources recently (since the
150's), so there may have been changes. I know I'm starting to see Makefiles
in directories where there weren't any before.

What I do know I want from a Gold v1 userland is a well documented API
> with a concept manual. The concept manual is a glossary/reference for
> any and all concepts in Gold, like Objects, Messages, Applications, and
> outlines the accepted practices of writing applications.


Yes. A documentation of the more unique concepts of gold (like events, files
vs objects (though not important for goldv1)) would help people get the
basics of how code is done in gold, and then a basic API documentation will
take them from there.

I see the "right" way to write applications as a kind of "lego
> building" exercise. For those who don't know, legos are child's
> plastic interlocking bricks which form complex structures, but
> themselves are simple "particles". Building an application would be a
> matter of collecting the right "legos", and stringing them all
> together. The interfaces of almost any service need to be compatible
> for similar services. If there's two services that can work on a
> specific type of object, and take one integer argument also, even if
> both services are in DIFFERENT providers they should be standardised as
> to argument order and expectation for the same nature of inputs. At
> some point in the distant future, around v2 or v3, perhaps this process
> can even be put into a trivial GUI.


I agree...applications would then just pick out objects they wanted to use
and string them together in a unique fashion. In fact, application design
could just be implementing classes for different components, and a thin
python script which instantiates them and puts them together.

Working with information should be fluid, and "intelligent". In
> traditional posix you must specify the location of "objects" you want,
> like: "/dev/null". We need a mechanism, like: "?null" or "?LSD_API.h"
> or something, where paths can be coded as meeting requirements. Like
> we've discussed, a database file structure would be ideal. Whether
> this belongs in kernel or userland is a topic of some debate, but I've
> made clear what I am willing to put into a kernel, and what I am not
> willing to put into a kernel.


For gold v1, I'd recommend a light filesystem. For gold v2, I think either a
purely database filesystem, or hierarchal+database-for-userland-data hybrid
would be cool to toy with.

I think if we go database, some kind of regular expression like syntax would
be a cool way of identifying objects.

 Again, SACROSANCT among my concerns is proper documentation. RTFS is
> an invitation for me to burn you alive in molten lava. Working with
> files once accessed shouldn't be normally in the traditional "stream"
> sense, forks aside. I want to be able to work with files as "entities"
> who know how to do their job. As an application programmer, if I open
> up a file which is of general classification "media" and tell it to
> "play itself" it should know what to do, or rather the system should.
> From the perspective of the applications programmer, the whole system
> exists to arbitrate this and other services.


I agree entirely. This would really cut down on people re-implementing
existing functionality. We only need ONE mp3 decoder. ONE window manager,
etc., on the system at any given time. One could exchange one mp3 object
implementation with another, but they should be expected to be supersets of
some core amount of functionality other applications expect. One mp3 decoder
might have code to alter id3 tags, another may not, but they both can play
the song.

*snip*

 Oh, transparent access to all data on any location. If I have
> security clearance to view something, that "something" should be
> accessible by the same means, regardless of where it is. Network data,
> web data, ftp, ssh, samba, filesystems, and anything else should be
> accessible transparently. Program output should be treated as a form
> of this data, and programs should be attachable to nodes for IO. This
> is like pipes in the next generation. Now a program's output can be
> treated like any other object, and I can attach as a client to any
> running program to interact with it.


Indeed. However, this isn't exactly lines of text we're 'piping,' these are
live objects. Are we going to store binary dumps of objects, and 'inject'
them into another binary, then send an event? For example, say I'm a UNIX
terminal application. I likely have an object that exists in GUI land which
displays characters and handles cut and paste (and more), as well as a
control object that we would think of as the Terminal itself. If an SSH
Session object is finished authenticating and loggin in to a UNIX box, and
we want to connect it to a running Terminal, do we take a binary dump of the
object, stick it in Terminal's address space, and send Terminal a
'receive_session' event?

The Terminal could be accepting such objects from SSH, telnet, or any other
arbitrary protocol. The code to handle the protocol must exist in the object
being sent, but have a standard way to tell the terminal things like "the
user just pressed key #84" or something like that.

Probably my lack of experience in writing terminals is showing, but I hope
the example makes the point clear: need a well-defined way of creating
objects that are intended to be detached from one process and sent to
another. And I'm sure it's more than just a binary copy...a fair amount of
RPC handshaking and security related authentication obviously would need to
take place.

Which is not currently available in Linux, at least :)

*snip*

> I await your thoughts,

> >
> > - Justin
>
> --
> Adam David Alan Martin
>
>
Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/gold-devel/attachments/20051020/0c544b46/attachment.htm>


More information about the gold-devel mailing list