to open a few more cans of worms, consider these issues:
- https://github.com/w3c/activitystreams/issues/610
- https://github.com/w3c/activitypub/issues/367
it really appears developers have made quite a habit of misusing
(misunderstanding?) fragment identifiers. we would like to fix that, if
possible.
(alternatively, we could work to redefine fragments as being "whatever
the application feels like", i.e. make them non-portable. they
effectively already are, but the current state of things is not working
particularly well for anyone involved.)
On 2024-08-07 13:58, Soni "It/Its" L. wrote:
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
--
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]
