Better uri syntax

[sertonix]

Have you checked for existing feature requests?

• [X] Completed

Summary

The current atom: uri system is very chaotic. Maybe it is used and else it is interpered as a file. Since we can't just rework the atom: syntax cause of compatibility I suggest making a new syntax for a pulsar: scheme. The new api could be scheme independent and therefore better for rebranding.

My Ideas would be something like this:

pulsar://open-file/path/to/ansi/file.txt?encoding=ansi
pulsar://new-file?content=some%20text?langauge=gfm
pulsar://package/settings-view/package-manager/show/my-package
pulsar://package/settings-view/package-manager/search?q=search%20string
pulsar://open?dev-tools&dev

In generic: pulsar://<action> with more parameters depending on the action. And also pulsar://package/<package name>/<action> for actions from packages.

One thing that should be prevented is a uri executing code directly like force installing a package without asking the user.

Also it would be nice to follow the uri syntax more strictly and add uri parsing to the core.

Enter your response below:

A system that defines at the start what it does would make finding issues like this much easier.

Any alternatives?

Having a inconsistent and hard to debug uri scheme that also can't be rebranded.

Other examples:

No response

[confused-Techie]

So I know this is super old, but does closely relate to a feature I was attempting to implement some time ago.

Where I discovered something, essentially the URI of atom:// like you said is required, that's the only valid schema of a URI.

Whereas the next bit depends on a few things. But essentially what comes after the last parts of the URI, is handled totally by whatever package it points to. So there is no way we could actually prevent a URI preforming actions at all, since it's not really handled in any central location.

So that says that if Pulsar sees the URI atom://package/settings-view/my-awesome-feature Pulsar only hands that off to the package of settings-view but beyond that does nothing. So the package itself would have to implement any cool features based off that.

I think the only thing we could do to improve this, would be a a atom global API that can help decode the URI, or we can optionally pass an object based URI to packages that's already decoded, this way we can ensure the syntax will always follow a valid URI schema, but as for what packages do with that information it'd still be up to them.

[sertonix]

I do aggree that packages should be able to use URIs outside of a standard pattern (for the hackability). But for a more consistent style in Pulsar it should be easier to make a URI with the standard pattern. Essentially any package that does there own think would do that at there own risk but if a package uses the standard functions every bug is a bug from Pulsar.

[confused-Techie]

That's a good point, but I'm also saying that currently we do nothing to the URI for a package. If we suddenly start processing every URI, and make a package register what every endpoint of a URI does, we'd have to build two URI systems, or break existing ones.

[sertonix]

I don't see a way to not have 2 URI systems. Maybe with a compatibility layer that mocks the old version to work with different URI schemes.

[confused-Techie]

So actually, I really should've read the docs closer on this subject before responding.

We already do all of this. The Docs.

When Pulsar hands a URI to a package, it's already a fully parsed object. As far as I can tell, this object is parsed according to the URI spec.

So everything we are talking about basically already exists. Except limiting what runs with that URI. Which already as of now a package does have to register their URI method, so we already do call a very specific function. But it's still up to the package what it does with this data.

So now knowing that, is that essentially what you were hoping for? Or what would a solution look like to you? @Sertonix

[sertonix]

When Pulsar hands a URI to a package, it's already a fully parsed object. As far as I can tell, this object is parsed according to the URI spec.

From what I remember the URI ( at least in the Pulsar core; also settings-view I think ) is matched as a full string rather than an object. I currently don't have the capacity to check, sorry.

[sertonix]

If a parsed object is used and only the path is checked that should be fine for now. More hackability would be available if packages could register more URI schemes which would mean that the scheme would need to be checked in some way.

[confused-Techie]

Yeah checking settings-view I'm seeing this in the registered URI handler:

handleURI (parsed) {
    switch (parsed.pathname) {
      case '/show-package': this.showPackage(parsed.query.package)
    }
  },

So does look like we are still using a fully parse path.

So maybe we are good to close this one? Since the tools are there for packages to take better advantage.

But more URI schemes could be interesting, have any in mind? Or related to the original links you posted?

[sertonix]

There are existing URI schemes for a lot of things like mailto, torrents, IRC or even http/https which may could be used by packages. Similar to how emacs can be used for anything.

[sertonix]

So maybe we are good to close this one?

It does seem like it. If the hardcoded URI scheme still exists in the core that should be a new issue though.

[confused-Techie]

Well specifically mentioning http/https as far as I know, you have to use a custom namespace that's then registered to an application for a URI on the web to be used within the application, such as atom:// or if we wanted pulsar://. So while we could use new namespaces, it wouldn't do much to improve the feature set of values allowing within that namespace. Since if we did start registering new namespaces as belonging to Pulsar, that'd cause them to opened within Pulsar only, and cause the applications that rely on them to break.

But as for implementing pulsar:// it seems the current concern is around breakage, which I know wouldn't be a factor if we had both, but last it was discussed I know there wasn't a huge interest in it.

But if you feel what we've discovered is suitable enough for you issue we can close, because of course if there's still a valid concern I'd wanna make sure we leave this open and can get it resolved

[sertonix]

The snippets package doesn't uses the uri path properly. But yes that would be a breakage problem.

Edit: link

As I said 1 URI scheme should be fine for now. Was only an idea if the basics are working.

[confused-Techie]

So looking at that, the link itself is registering a URI, so it isn't actually dealing with a parsed snippet. And I think the reason it has the dot is because it's referring to opening the file .pulsar/snippets and that's why it opens the user's snippets file. Albeit it does look a bit strange. But yeah changed that path would cause some breakage

[confused-Techie]

But fair enough, if you think things are fine for now, then we can close this one out. Sorry it took so long to properly get to @Sertonix, and I really appreciate you taking the time to talk this one out with me!

[sertonix]

Oh, just remembered something. Please, for anybody that has to debug the uri system: Don't interpret unregistered URIs as paths! This is awfull. Do something like open-path/<path>. And I am very confident that every package that may break through this change will be worth it for the time used less on debugging.