Re: [JOS-Kernel] Device as a digital resource

[Gilbert Carl Herschberger II]

At 05:05 PM 3/18/00 +0200, Al <[EMAIL PROTECTED]> wrote:
>I don't really like the scheme, because it is not the normal way a URI
>works. The above URI actually does not point to a device, but merely
>informs how to search for a device.

I propose a system-wide device factory. I propose that we can treat
JVM-specific classes and devices in a uniform way. I'm sorry you don't like
the scheme. Oh well, it was my first attempt to map devices independently
from the traditional ideas of a file subsystem.

Do you like that idea of a system-wide device factory?

Do you like the idea that a URI is used to identify devices? If so, we can
refine the scheme through experimentation.

I was thinking this URI should specify the interface you would like to use.
The same interface might be used for all serial ports. Like BCNI, it would
be much easier to finish this project if there is a direct link between a
URI and the JOS Platform API.

Properties can be set before or after a device is returned. Either way a
device is returned. While the device: scheme can set properties before, the
bcni: scheme requires you to set properties after.

>The above URI could *point* to a modem device like this:
>
>for the serial port 1,
>
>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.

>The parameter indicator question mark ('?') should, IMHO, be used for
>parametric information only, such as:
>
>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.

Once a modem device is created, port is one of its properties. Since port
is a property, I put it in the query string with all of the other
properties. In general, I would prefer to put port in a query string
because there are many devices without a port.

We disagree on the concept of path. Devices should be mapped independently
from the traditional ideas of a file subsystem, like path.

>device://localhost/devices/ports/parallel/0/?bidirectorial=true

Look! See how easy it would be to set properties of a device with a URI.
After a device is created, you change its properties with methods.

Host and port should be optional, not required. At first, none of these
devices are capable of distribution. They are always local host. A device:
scheme could start out like this:

'device:' [ '//' host [ ':' port ] ]

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. 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.

Once we see the similarity between JVM-specific classes and devices,
devices can be designed and used in all kinds of Java programs.


_______________________________________________
Kernel maillist  -  [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel