Jordi Boggiano Wrote:
Feels weird to have str implement something specific to another module,
but if there is no other way it sounds more user friendly than a
gazillion open_* methods.
A few more comments on other things:
- Streams are great, and the ability to register new stream protocol
handler for "foo:..." urls would indeed be a big plus.
I agree; it's great that locations other than local file paths is being
considered, especially in the context of general streams. BUT, I think
the right thing would be to support URIs, rather than just URLs. For
example, supporting URIs would also allow accessing URNs like:|
|
open(Uri("magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C"))
"Get some data, identified by a SHA1 hash, from whichever data
sources you have."
For instance, this is popular on p2p networks, but is probably
equally valid for, say, providing data from multiple key/value stores
(say, MongoDB and LevelDB), in a database-independent way.
open(Uri("urn:isbn:0451450523|"))|
"Open the book with the given ISBN number."
open(Uri("urn:issn:0167-6423"))
"Open the Science of Computer Programming Journal."
open(Uri("|urn:ietf:rfc:2648"|))
"Open IETF RFC 2648."
My point is simply that there's more out there than just URLs, and if
we're designing a stream API, it would be sensible to support the full
range.
- open vs connect, I'd say open. Opening a connection sounds ok,
connecting a file sounds awkward.
Yep.
--
Lee
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
