File Type Official List

@ROOL Guys As you are responsible for maintaing the list of registered file types, I was wondering if it was possible to get a snapshot, so we can update the wiki with it?

I realise that there are unoffical listings on the web, but thought it would be good to get an official list. Don’t worry, I wouldn’t want a frequent updates.

The place holder page is at file types. I’m more than happy to wiki-fi it.

Yes, we do have the official list. We cannot release because the allocations database is confidential and without going through all of the allocations to figure out who they belong to and then ask their permission, we’re stuck.

The traditional position of the people who run the allocations system – and the position of ROOL - is that we won’t release that.

If you want to build a best guess page in the wiki, then that’s fair enough (StrongHelp manuals also have a list in them – I’m sure there are others). I’m sorry it doesn’t sound like we’re being very helpful, but I’m sure you can understand our dilemma.

Not a problem. Just thought I’d ask in case it was possible.

I’ll ask around and see if I can use an unofficial list from somewhere.

Thanks for the prompt reply.

Being totally inexperienced with law or business of any kind, I am mystified by this confidentiality of the filetypes database. What was the reason for it? What possible insecurity could registrants be exposed to by its publication? Mystification aside, I think a new, unofficial, democratic wikified version would make a lot of sense. Would it be a heinous offence were some public-spirited deep-throat to whisper that certain entries on the wiki were incorrect?

I think in the past when RISC OS still supported a commercial marketplace, the idea was that companies could register filetypes, SWIs, etc, while the product was still in development. Keeping it confidential was important then, to stop competitors guessing what they were up to.

Things are a bit different now, but given that there’s widespread unofficial info on filetypes, I can see why ROOL are keen to keep the filetype list confidential. It’s still possible that a company, even one that doesn’t trade in the RISC OS market, might object to information being made public that was submitted with the expectation of it being kept private.

All AFAIK, IANAL, IMO, etc.

Chris: that’s exactly correct.

It’s a bit pants, but that’s the situation we’ve inherited since taking over the administration of the allocations system.

The previous administrator (or a predecessor, I’ve lost track) was slightly more flexible when asked nicely, so I also have a full set of allocation files, up to whenever it was I got bored.

Steve, ist it possible to change the future allocation scheme to ‘will be released to public after publication of product’? So there could be 1) a confidential list and 2) a public, but still official list. Producers of already existing software can choose to modify their agreement to get their product to the public official list too, but do not need to. This way we get things straight for the future without legal pitfalls.

Thanks to Stephen Courtney of the RISC OS filebase web site I have now uploaded a comprehensive list of filetypes in the ROOL wiki here.

It seems a filetype I registered for an application of mine, DirSync, is not in the list. What do I update? The RISC OS filebase list (assuming it can be updated) or the ROOL wiki?

Firt port of call, should be the ROOL wiki – simply because anyone can now update it.

If you feel, inclined, you could also email Stephen @ filebase, to see if he’s interested in keeping his up-to-date.

The ROOL wiki link returns an ‘empty document’ error in NetSurf…

The ROOL wiki link returns an ‘empty document’ error in NetSurf…

Yes, the wiki is down again, hence the error.

There is a bug that causes the wiki to go down (which happens pretty much every day when I’m creating/editing pages). I cannot pinpoint the exact cause of it, but it seems to be related to the amount of data transferred since the last reboot.

Its really quite annoying, as it a) stops me from updating the wiki, and b) stops all users from accessing the wiki.

The bug has been reported to ROOL, and is on the bug database. Here’s hoping that it will get resolved soon. But I’m not holding my breath on this one!

The fix is unfortunately not a simple one. We have been looking into alternative wikis and other aspects of our web site but actually updating it is a big job. I’ll let Andrew tell you all the ins and outs, but suffice to say we’ve been working on a number of web site updates recently and have some prototypes for the new website working to some degree.

For the time being, you will just have to wait for the nightly restart of our web services. Or, email us at info@riscosopen.org and we can give it a kick manually if needed.

We have been looking into alternative wikis and other aspects of our web site.

Thanks for the heads-up. Looking forward to it.

For the time being, you will just have to wait for the nightly restart of our web services. Or, email us at info@riscosopen.org and we can give it a kick manually if needed.

Although I find the wiki situation irksome, I’m well aware that you guys have much more important items on your agenda, such as source releases and all the legal work that goes with it. I’ll just wait for the daily reboot, but thanks for the offer.

I don’t mind getting an email asking for a manual kick – it only take 30 seconds out of my day. However, there’s no response time promise!! :D

okay, I’ll take you up on your offer.

No SLA required ;)

We have various updated Ruby On Rails applications running on a development machine, but there’s lots of work to get those all styled to match the ROOL site, fix any bugs and, hardest of all, integrate them with the Hub single sign-on mechanism. We’re showing the latest stand-alone applications at the Birmingham RISC OS show today.

We used to use Instiki for our documents section, but the project died and it had lots of bugs. Shortly before launch I was forced to move to I2, which we still use – far fewer features, but far fewer bugs. Instiki has since been brought back to life and is currently developed, so if I fix bugs I can submit the fixes back to the project maintainer. This makes it a much more viable thing to use in a future site revision.

Most useful features: Arbitrary file attachments, including inline images within pages; visual diff between page revisions; export of all pages in a ZIP archive of XHTML or TeX files. Watch this space! I hope to have something going live within the first half of next year (can’t be more specific than that, sorry, just too busy).

Most useful features: Arbitrary file attachments, including inline images within pages; visual diff between page revisions; export of all pages in a ZIP archive of XHTML or TeX files.

Looking forward to the inline image support. Will come in handy from time to time. And I see great benefit for ROOL and its users, to be able to be able to create a zip file of the documentation too.

I hope to have something going live within the first half of next year.

Looking forward to it :)

Thanks to Stephen Courtney of the RISC OS filebase web site I have now uploaded a comprehensive list of filetypes in the ROOL wiki here.

It might be a long list, but it’s certainly not comprehensive. None of the types I’ve registered in the last ten years appears on it, so just for the record, I don’t want anyone assuming it really is a comprehensive list.

Might be better if the RISC OS Open wiki directed people to the ANS filebase page, as that offers download in CSV format and other features? Now we risk a fork in this information, unless someone can guarantee the two pages will be kept synchronised.

Should I post my registered filetypes to ANS to get their list updated, or the ROOL wiki?

Might be better if the RISC OS Open wiki directed people to the ANS filebase page, as that offers download in CSV format and other features?

If people feel strongly about having a source of filetypes available on the ROOL wiki, it can as you say be changed to point to the ANS list.

The reason I posted the list on the first place was a) for completeness of the ROOL wiki, and b) it allowed for anyone to update it they wanted.

Should I post my registered filetypes to ANS to get their list updated, or the ROOL wiki?

I suggest posting it to ANS - assuming Stephen still updates it. You can, however, update the ROOL wiki…

If others are against the filetype list on the ROOL wiki, let me know and I’ll remove it. I’m really not bothered about it.

I’d urge maintaining a collaborative list, “official” or not. The ROOL site is the best place for this. Lists/FAQS/etc maintained by individuals are notorious for going out of date for whatever reason (riscos.org for an extreme example). With a wiki, anyone can update if they feel entries are missing, as well as put notes on unofficial types, etc, etc. This type of content is less suitable for the riscos.info wiki, but I’ll host it there if need be. As it is, riscos.info could do with an entry referring to the ROOL wiki discussing filetypes in general.

I agree – it would be great if the list was available with some kind of API-access too, that way other sites / software could use it too. !TypeInfo could be updated (or something similar released) that could query the system in realtime too.

Stephen

Just remember this: editing the list in our wiki does not constitute making an allocation and, for the reasons I gave above, don’t expect ROOL to maintain the list on our wiki. This is a community-owned page.

As for having a web-based front end onto the allocations system for making your allocations, this is definitely something we’ve thought about in the past and I would like to see it happen one day.

It might be a long list, but it’s certainly not comprehensive. None of the types I’ve registered in the last ten years appears on it,

Whilst it may be confidential that a particular company registered a filetype or that it was registered for a particular purpose, it is not confidential that it has been allocated and is no longer available. So I suggest that filetypes that have been allocated but where no publicly available application surfaced (i.e. the filetype is allocated but the table entry is currently blank) then there should be an entry ‘allocated’ against that filetype.

The ‘personal use only’ section is clearly not allocated, just whatever any user felt like doing. Should filetypes which have just been used and never had an allocation be marked as ‘unofficial’ in some way? For example I have used the filetype &EFB for a BASIC file that has a different default run action but can’t remember why I did that nor have I used it for the last 15 years or so.