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

[Adam Martin]

On 2005 Oct 19 , at 19:34, Justin Hibbits wrote:

> Alright, to make good use of the mailing lists:
>
> What exactly do we want to provide to a) the user, and b) the 
> developer?

	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.

> Adam posted the list of classes we came up with in March, but I don't 
> think
> it's complete enough, and the behavior isn't fleshed out.  So I ask 
> you guys.

	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.

	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.

	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.

	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.

	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.

	From a security standpoint, authd being the extension of LSD's 
security model, and being our way of performing verified privilege 
escalation for limited purposes, is fine for v1.  I would like to see 
some active anti-intrusion mechanisms in v2, and perhaps some work in 
network security?

	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.

> I don't want a list of classes, I want a set of behaviors that we as 
> an OS
> provider -- kernel, user libraries, and user interface -- should 
> provide.

	Not to echo what is in the LSD_API document, but I'll give a brief 
explanation of LSD concepts, functionality, and mechanisms.

	In LSD we have a few fundamental concepts to learn about, and master, 
if you have not already:
Files, Forks, Events, Kernel Message Buffers (and KMB Pages), Event 
Buffer Pages, Event Handlers, Compound Symlinks, Threads, Monitors, 
Processes, Synchronous and Asynchronous system services, new permission 
semantics, and a few other things.

	I'd write more but I'm passing out at the keyboard.  I'll probably 
write more in an hour or so.

> I await your thoughts,
>
> - Justin

--
Adam David Alan Martin