<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> As far as userland functionality above the kernel, I do not think I'm<br>too qualified to speak on this. For kernel services, I will TELL you
<br>as much as I can here.</blockquote><div><br>
I personally don't think there should be too tall a stack between LSD and userland. <br>
</div><div><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Justin, you came up with those classes, I just posted. Why not flesh<br>out their purpose, and entry points, and such? At least all that you
<br>can think of.</blockquote><div><br>
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.<br>
<br>
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?<br>
<br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> What I do know I want from a Gold v1 userland is a well documented API<br>
with a concept manual. The concept manual is a glossary/reference for<br>any and all concepts in Gold, like Objects, Messages, Applications, and<br>outlines the accepted practices of writing applications.</blockquote><div>
<br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I see the "right" way to write applications as a kind of "lego
<br>building" exercise. For those who don't know, legos are child's<br>plastic interlocking bricks which form complex structures, but<br>themselves are simple "particles". Building an application would be a
<br>matter of collecting the right "legos", and stringing them all<br>together. The interfaces of almost any service need to be compatible<br>for similar services. If there's two services that can work on a<br>
specific type of object, and take one integer argument also, even if<br>both services are in DIFFERENT providers they should be standardised as<br>to argument order and expectation for the same nature of inputs. At<br>some point in the distant future, around v2 or v3, perhaps this process
<br>can even be put into a trivial GUI.</blockquote><div><br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Working with information should be fluid, and "intelligent". In
<br>traditional posix you must specify the location of "objects" you want,<br>like: "/dev/null". We need a mechanism, like: "?null" or "?LSD_API.h"<br>or something, where paths can be coded as meeting requirements. Like
<br>we've discussed, a database file structure would be ideal. Whether<br>this belongs in kernel or userland is a topic of some debate, but I've<br>made clear what I am willing to put into a kernel, and what I am not<br>
willing to put into a kernel.</blockquote><div><br>
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.
<br>
<br>
I think if we go database, some kind of regular expression like syntax would be a cool way of identifying objects.<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Again, SACROSANCT among my concerns is proper documentation. RTFS is<br>an invitation for me to burn you alive in molten lava. Working with
<br>files once accessed shouldn't be normally in the traditional "stream"<br>sense, forks aside. I want to be able to work with files as "entities"<br>who know how to do their job. As an application programmer, if I open
<br>up a file which is of general classification "media" and tell it to<br>"play itself" it should know what to do, or rather the system should.<br> From the perspective of the applications programmer, the whole system
<br>exists to arbitrate this and other services.</blockquote><div><br>
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.<br>
</div><div><br>
*snip* <br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Oh, transparent access to all data on any location. If I have<br>security clearance to view something, that "something" should be
<br>accessible by the same means, regardless of where it is. Network data,<br>web data, ftp, ssh, samba, filesystems, and anything else should be<br>accessible transparently. Program output should be treated as a form<br>
of this data, and programs should be attachable to nodes for IO. This<br>is like pipes in the next generation. Now a program's output can be<br>treated like any other object, and I can attach as a client to any<br>running program to interact with it.
</blockquote><div><br>
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?<br>
<br>
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.<br>
<br>
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.<br>
</div><div><br>
Which is not currently available in Linux, at least :) </div><br><div>*snip* <br>
</div><div><br>
</div>> I await your thoughts,<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> - Justin<br><br>--<br>Adam David Alan Martin<br><br></blockquote></div><br>
Nathan<br>