A proposal for strongly typed resource identifier (draft)
Created by: zonyitoo
Redox is outstanding because it introduces the concept of "Everything is an URL". But because URL is a well known word, which particularly refer to IANA URL, so would be better to use a different protocol with different name, refer to #175 (closed) .
But CURIE is actually a String, which makes it impossible to validate in compile time. So to make use of type checking, I propose to use a strongly typed resource identifier.
Key Points
- Use CURIE as a stringify method of the resource identifier.
- Resource identifier and transfer protocol is strongly typed.
- Make good use of Rust's type system.
Proposed Resource Identifier
NOTE: This may be completely wrong, please just stick to the key points.
Let's name this Resource Identifier as Ri
(abbreviation of Resource Identifier), and it could be defined as
trait Ri<'a>: Curie {
type Provider: Resource + CurieScheme;
type Reference: CurieReference;
type Parameter: CurieQueryString;
type Fragment: CurieFragment;
type Input: Sized;
type Output: Sized;
type Error: Sized;
fn provider(&'a self) -> &'a Self::Provider;
fn reference&'a self) -> &'a Self::Reference;
fn parameter(&'a self) -> &'a Self::Parameter;
fn fragment(&'a self) -> &'a Self::Fragment;
fn read(&mut self) -> ReaderIter<Input>;
fn write(&mut self, output: Self::Output) -> Result<(), Self::Error>;
fn from_curie<'a>(curie: &Curie<'a>) -> Self;
fn to_curie(&self) -> CurieBuf;
// Compact serialization
fn serialize(&self, w: Write) -> io::Result<()>;
fn deserialize(r: Read) -> io::Result<Self>;
}
Could be converted from/to CURIE formatted string
The definition matches the definition of CURIE syntax
provider:reference?param1=1¶m2#fragment
so Ri
could always be serialize/deserialize to/from CURIE formatted string.
Also it is a good way to provide FFI interface for other languages to call.
Resource Protocol
All resources have a well defined provider, so the data transfer protocol is already defined by the provider. Such as the file
provider could read
and write
a [u8]
, http
provider could read
a HttpRequest
and write
a HttpResponse
.
So the author of that resource provider will need to restrict the input and output protocol by defining Input
and Output
data structure.
Note
This is just a draft propoal, implementation detail should be discussed further.
There are at least the following problems to be solved
- Performace. Using strongly typed definition may involve performance issue, it needs to be designed properly.
- FFI compatible. Because Redox is an OS, so the APIs will be called from various programming languages, but strongly typed APIs in Rust will become an obstacle for the other languages.