Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide and document XDG media type #4746

Closed
Akselmo opened this issue Apr 24, 2023 · 9 comments
Closed

Decide and document XDG media type #4746

Akselmo opened this issue Apr 24, 2023 · 9 comments

Comments

@Akselmo
Copy link

Akselmo commented Apr 24, 2023

I've created an issue to XDG mimetypes repo about adding a mediatype for robot framework
https://gitlab.freedesktop.org/xdg/shared-mime-info/-/issues/198

I think having mediatype text/robotframework would be ok. This means any text editor would know it's a text file, and those which have syntax highlight etc. support for Robot files can enable that as well.

@pekkaklarck
Copy link
Member

An official media type sounds good. I don't know much about them, but text/robotframework sounds good. In addition to agreeing on that, we need to document it. Probably best to add an appendix to the User Guide where we could also document our file extensions and the registered remote server port.

@pekkaklarck
Copy link
Member

I added an appendix to the User Guide where the text/robotframework media type is mentioned along with the file extensions and the remote server port that is officially registered by IANA.

In comments of the issue @Akselmo submitted about adding text/robotframework to XDG shared-mime-info, it was pointed out, that it would be even better if the media type would be registered with IANA. I believe that makes sense in general and especially because they have already registered the remote server port.

Are you @Akselmo interested to look at the IANA registration? If you don't have time or interest, I can take care of that myself or ask could someone else do that. We can discuss more about that on Slack.

@pekkaklarck
Copy link
Member

The aforementioned changes to the User Guide are enough considering RF 6.1. I leave this issue open until we get the media type registered, though, and after that documentation also needs to be updated with a link to the IANA database.

@pekkaklarck
Copy link
Member

I spend a little time studying media types to get a better understanding on then.Here are some resources:

  • IANA media types. Contains a bit of generic info, links to more info, and a list of registered media types.
  • IANA media type application form.
  • Various RFCs linked from the above pages. They are very detailed and cover also other MIME related topics than media types. I only took a quick look on some of them.
  • Media type Wikipedia page. This explains the media type syntax in simpler and more condensed manner than the aforementioned RFCs.

Based on my quick study, there are some things we need to decide:

  1. Should we register to the "standards tree" or to the "vendor tree"? The former contains types like text/plain and image/png, and text/robotframework would fit there nicely. The latter is for publicly available products and it could be argued that Robot Framework would belong there along application/vnd.ms-excel and image/vnd.adobe.photoshop. If we'd go that route, then we also needed to use text/vnd.robotframework. I believe the standards tree is better, but I don't know are there restrictions with that.

  2. Do we need to be able to separate suite files (*.robot) and resource files (*.resource)? If we do, how? The vendor tree would allow using a "tree prefix" like texts/vnd.robotframework.resource, but the standard tree doesn't. Media types also have a suffix, but it doesn't seem to be applicable in this context.

@Akselmo
Copy link
Author

Akselmo commented May 4, 2023

Are you @Akselmo interested to look at the IANA registration? If you don't have time or interest, I can take care of that myself or ask could someone else do that. We can discuss more about that on Slack.

It's probably better if someone from RF foundation or anyone who works more closely with RF handles that. I have no idea how IANA works... Nor really have the time unfortunately.

2. Do we need to be able to separate suite files (*.robot) and resource files (*.resource)? If we do, how? The vendor tree would allow using a "tree prefix" like texts/vnd.robotframework.resource, but the standard tree doesn't. Media types also have a suffix, but it doesn't seem to be applicable in this context.

If I understood it correctly, the XML file looks for file-ending, then for some "magic-string" within the file. I think those magic strings could be all the test data sections parts, such as *** Settings ***. We can be quite sure it's a RF .robot or .resource file if it has one of these sections within.

Currently the files are thought to be patchfiles by many desktop environments that follow XDG standards, due to them having also the magic string of *** stuff ... However specifying that if the file has one of those asterisk sections and ends with a file-ending .robot or .resources should be enough for it to differentiate.

@pekkaklarck
Copy link
Member

I don't think the person registering the media type needs to be that directly associated with the foundation. The remote port was registered by someone from Oracle, but the foundation was the assignee. Totally understood if you don't have time or interest for this, though.

With the XML file do you mean how media types are configured with XDG, right? The IANA application form also asks for things like file extensions and magic numbers. I believe magic numbers mean bytes in the beginning of the file and that isn't applicable with us.

The main open questions are:

  • Should we use text/robotframework, as discussed earlier, or go with text/vnd.robotframework? I like the former more.
  • Should we use same media type with both .robot and .resource files? I believe that's fine. Tools that want to show resource files separately can either look for the extension or does the file contain *** Test Cases ***.

Related to the latter point, I noticed that the example in the issue you submitted only contains <glob pattern="*.robot"/>. Shouldn't it also have <glob pattern="*.resource"/>?

@Akselmo
Copy link
Author

Akselmo commented May 4, 2023

Totally understood if you don't have time or interest for this, though.

No time and not really interest either 😅

Should we use text/robotframework, as discussed earlier, or go with text/vnd.robotframework? I like the former more.

I am fine with either, former may be better. :)

Should we use same media type with both .robot and .resource files? I believe that's fine. Tools that want to show resource files separately can either look for the extension or does the file contain *** Test Cases ***.

I think so yes, since they're both robot framework related items. No need for having multiple media types IMO.

Related to the latter point, I noticed that the example in the issue you submitted only contains <glob pattern="*.robot"/>. Shouldn't it also have <glob pattern="*.resource"/>?

Yeah I seem to have forgot the resource file from that snippet 😅 It was also missing the magic number/strings.

@pekkaklarck
Copy link
Member

pekkaklarck commented May 4, 2023

I don't think magic numbers are applicable with us. Robot files often start with a header like *** Settings ***, but that's not guaranteed. First of all, any data before the first such header is just ignored and the header format also supports e.g. * Settings.

@pekkaklarck
Copy link
Member

I looked at IANA media type registration again. text/robotframework would need to be registered in the standard tree and that process is pretty heavy. Getting it registered in the vendor tree would be easier, but then the media type would be text/vnd.robotframework. That would differ from what we decided to use with XDG which wouldn't be great. Probably best just use text/robotframework without official registration. It can be done later if there are concrete needs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants