the data URI is pretty neat, tho it did end up raising some pretty
unfortunate security issues in the long run.
for context, here's how various tools (mis)use "URIs":
- https://man.archlinux.org/man/PKGBUILD.5#USING_VCS_SOURCES
- https://www.mercurial-scm.org/doc/hg.1.html#urls
-
https://packaging.python.org/en/latest/specifications/version-specifiers/#direct-references
the problems we show here are not at all comparable to data URIs.
further, actively exposing users to meta-URIs teaches them a viable
alternative to the above mess.
(side note, as an example of a tool that, at first glance, appears to do
it correctly,
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories
)
On 2024-08-07 12:21, Ted Hardie wrote:
Greetings,
May I suggest you take a look at the specification for the data uri
scheme in RFC 2397 (https://www.rfc-editor.org/rfc/rfc2397)? It's
solving a problem related to the one you describe, and it might be a
useful document to keep in mind as you describe the use cases you want
to address and the mechanisms you propose.
I've read your draft and the text below, but the cases in which this
approach might be useful are still elusive for me.
regards,
Ted Hardie
On Wed, Aug 7, 2024 at 3:54 PM Soni "It/Its" L.
<[email protected] <mailto:fakedme%[email protected]>> wrote:
datatracker URI: https://datatracker.ietf.org/doc/draft-soni-meta-uri/
we made a previous post on meta-URIs, it didn't get any responses but
we'd like to discuss additional use-cases.
you've already heard of the auth URI idea, our proposal to ultimately
kill userdata altogether. that's far from the only use-case however.
we could have a mercurial URI, which would enable click-to-clone
functionality. mercurial supports ssh and http protocols, so
embedding
an entire ssh or http URI (instead of making an entire custom
syntax) is
just convenient. the fragment identifier can be used for some things
(e.g. subtrees, we're not sure if mercurial supports subtrees, but
the
idea is to filter out the repo so it only shows a specific
subdirectory,
instead of the entire repo. this is entirely client-side.) but other
things would be a little out of place in the fragment identifier
(things
that require server-side processing, like the clone depth, what
branches
to fetch, etc should *probably* go on the meta-URI instead of the
fragment?). this would also have the added benefit of better
interoperability with distro packaging tools, if the meta-URI has the
appropriate extension points for distro use. distros already use URI
schemes to distinguish VCS sources from HTTP sources, but they
each seem
to make up their own and don't register them. (this is where you get
things like git+http, hg+http, and let's not get started on what
they do
with fragment identifiers...)
but we might need to update RFC3986.
--
plural system (tend to say 'we'), it/she/they, it instead of you
--
Witarea mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
plural system (tend to say 'we'), it/she/they, it instead of you
--
Witarea mailing list -- [email protected]
To unsubscribe send an email to [email protected]
