Gilbert Carl Herschberger II wrote:
> Do you like that idea of a system-wide device factory?
I do, and I also support that an operating system must be as wide as
possible. The more generalized information the underlying OS can give,
the more detailed processing of this information can be achieved at
higher levels of execution. Don't we try to do the same thing with the
kernel, that is, make the use of C code as little as possible, such that
it supplies only the absolutely necessary information for a JVM to run,
and then the rest is done in the higher-level language Java?
> Do you like the idea that a URI is used to identify devices? If so, we
> can refine the scheme through experimentation.
I love the idea of using URI for pointing to *anything,* as URI are very
scalable and dynamic in doing just that: pointing. I use a sort of URI
for my Registry API, for example. The file system will use something
like that. Browsers and network tools will use them. Why not make
everything pointable by URI's, and then have a central engine that reads
the URI, and appropriately initializes the correct managers, factories
and transport protocols?
> > bnci:modem://localhost/serial/1/
>
> Maybe you meant something like "device:modem://localhost/serial/1/".
> The bcni: scheme is a bridge to the BCNI factory. Both the bcni:
> scheme and factory require the name of a Java interface. It has no
> paths. It has only an interface name.
Yes, you are right, I have no idea how BNCI works, but the "device:"
protocol is what I was talking about. I understand that if BNCI uses
class names, then the URI's should be the way you propose. Of course,
have in mind, that they are not truly URI, they are simply arguments to
the BNCI interpreter, that merely *look* like URI's... The purpose of a
URI is to map a path to location, right?
> > bnci:modem://localhost/serial/1/?maxspeed=57600&parity=none
>
> This is good. I agree that any program that wants to set parity, bits
> and speed should use the query string. Any parameter set in the query
> string should be a property of the device. If you use maxspeed=57600,
> the device defines a getMaxSpeed() method that returns 57600. If it is
> capable of changing a property after it is created, a device defines a
> setMaxSpeed() method, too.
If all devices are Beans, then this would be trivial to implement. I
like this idea very much, and I think that's why Sun put a lot of effort
in Beans, because they are so manageable.
> In general, I would prefer to put port in a query string because there
> are many devices without a port.
If the URI points *generally* to a serial port, then yes, the port
should be placed in the query section. But the URI I wrote points
*directly* at serial port #1.
> We disagree on the concept of path. Devices should be mapped
> independently from the traditional ideas of a file subsystem, like
> path.
Why? All devices on a computer, at least contemporary computers, are
linked together on buses and through ports. We can definitely map any
device on a computer via a path, if this path begins with the local
computer, mainly, the motherboard. Since everything is on the
motherboard, one way or another, then everything can be mapped starting
at the motherboard...
> 'device:' [ '//' host [ ':' port ] ]
I don't think we need the port in such URI's, because they are not
mapping to a server/service on the machine, they are merely mapping to a
device. The interpreter will not *contact* localhost, it will only know
how to find the requested device. Only in the case of remote devices may
a port be necessary, and then we would have to decide which privileged
port JOS will use for the "Network Device Manager."
> I do not propose a network-wide device factory. I cannot create
> distributed devices at this point in the start-up sequence. Without
> TCP/IP, we could not possibly connect to another host. I propose a
> local URI because we don't have a network.
Naturally, the interpreter of the device URI's will default to
"localhost" if no host is specified. And if a host is specified other
than localhost, then it can throw something like
"ServiceUnavailableException" or "RemoteDeviceUnavailableException" or
equivalent. When devices are made distributed, then these exceptions
will not be thrown any more, but programmers will not have to change
their code in order to access this future feature.
> Like bcni: scheme, the device: scheme would do well to specify the
> interface it wants, wouldn't it?
>
> 'device:' [ '//' host [ ':' port ] ] interfacename [ '?' querystring ]
>
> I asked myself this question: If we already have the bcni: scheme, do
> we need a device scheme? I think the answer is 'Yes, we do.' The
> device: scheme could manage additional parameters/properties on a
> device by device basis. This could be very flexible.
It can be very flexible if we can use a method such as "getDevice(uri)"
which returns a device and then we are free to play with the device as
we wish. The last URI you wrote I like a lot... I was thinking of
possibly something like this:
bnci:jos.device.Modem:device://localhost/ports/serial/1/?maxspeed=...
The device manager returns the raw device, and bnci converts it into the
specified "jod.device.Modem" class.
Since more types of devices than modems can be attached to the serial
port, the device manager can only return the raw version of the device:
the port itself.
Maybe, during JOS start-up, a mapping facility can create shortcuts,
such as:
device://localhost/mapped/modem0/?maxspeed=...
is equivalent to:
bnci:jos.device.Modem://localhost/ports/serial/1/?maxspeed=...
What do you think?
--
"Learn from others' mistakes, for you won't live long
enough to make them all yourself..."
________________________________________________________________________
[EMAIL: mailto:[EMAIL PROTECTED]] [URL: http://www.outworld.org/people/al]
[TEL1: (30) +31 422392] [TEL2: (30) +31 428154] [CELL: (30) +937 110247]
[ADDRESS: 14 Argonafton St., Kalamaria, 551 31, Thessaloniki, Greece GR]
PLEASE DO NOT SEND ME ANY UNSOLICITED COMMERCIAL EMAIL [DSS: 0xDBEF8ECC]
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
