Versions

It's time I've decided the draft of major and minor release versions for doomhub.com. It will also tell you what kind of functionality you can expect in the future.


[PLANNED] v1.0 first release version

• Registered users can create projects.
• The project privacy level (public / restricted / closed) can be decided during creation and edition.
• Open projects are completely public, all their entries are readable by everyone, all their resources are downloadable by registered users, any registered user can create a map for those.
• Restricted projects can be read by anyone, but a user has to be invited to the project by a project-admin or project-mod to download a file or to create a map.
• Closed projects only show on the list, but are not readable at all by uninvited users.
• Creators of the projects are automatically made admins (project-admins) of them.
• If a project is closed or exclusive, a project-admin can invite other users to collaborate on respective projects. If a project is open anybody can add stuff for it.
• Project-admins can make other users project-admins or project-mods.
• Authorised users (map-authors) can create maps in respective projects.
• Map-authors can upload files (zip archives) for map, meant to include actual wad files of the maps.

[PLANNED] v1.1 resources, images and comments

• Project-admins and project-mods can add resources (like texture packs, text documents, images and stuff) to projects in general, rather than to maps only. They inherit privacy after the respective project.
• Map-authors can add images (screenshots) to their maps.
• Users can comment on maps (as long as they have access to see them).

[PLANNED] v1.2 per item permissions

• Map-author can specify privacy level per screenshot.
• Map-author can specify privacy level per wadfile attachment.
• Project-admin and project-mod can specify privacy level per resource file.

A more graphic presentation

Diagrams are always good.

So, at first I was like:

But then I was like:

You can clearly see the WADFILE, wich is a Paperclip attachment has been removed as an attribute from Map class and moved to a separate MapWadfile class.

Slow weekend

So I created a blog. Setting it up a took like 3 minutes total (including searching for a recommended one)... For the rest of the weekend I was fighting with permissions and attachments in the application. A few problems came out, which was unsurprising really.

What was surprising, is the fact these were not technical difficulties. I set CanCan (and learnt a lot about it... again) up, then I got Paperclip working with an AWS-S3 account. It was a first time I did something like this and it worked like a charm. Thank god for smart people writing smart software. Even made it possible to limit the uploads and downloads via the usage of HTTPS, rather than standard HTTP. It was all so deliciously simple:

A User with a proper UserRole can create a Project. A Project is defined by a Game it's designed for (Doom, Doom2, Heretic...) and an Engine (source port) it uses. The User can then proceed to create Maps for it. Each map has a Name (a "display" name), a Lump (the name of the lump it's supposed to be located with in the WAD) and a Wadfile, which actually is a zip archive, oh well. Of course the file name and location has to be automatically determined upon upload, so that it can be both downloaded or removed later with ease. This means the file name has to be static...

Then it struck me - what if the map author wanted to rename it?
It's not unheard of - people had done it a few times during the course of DTWiD development. The fact, that I wanted the filenames to be pretty and actually include a slug based on the Map's "display" Name didn't really help. Paperclip can't do this for me. Not on S3.

I started deliberating what would be better - to store the files with an id-only based names (which would  mean that when downloading people would get files named like so: 2-5-12.zip), or to include additional functionality to change file's name directly in the S3 repository. The first solution was ugly, the second one was resource heavy. Things like that would probably require dedicated worker processes to pull it off and I can't really have those on a shared web hosting.

Then it struck me again - leaving me barely alive.
I got it all wrong. Not to mention neither solution would really be reliable enough.
I just have to separate the Map entity from a Wadfile entity. A single Map will be able to have a couple of related Wadfile class objects, each one of them named automatically, or manually (User's choice) and each of them managed independently, with only create and delete actions to chose from. This means changing the name of the Map will not bother the file at all. The author would then have to decide if he wants to reupload the file with a new name or leave it as is.

The beauty of it is that it's so much easier to do and it allows a Map to have a couple of files, like different versions of work in progress.
...but I should probably limit it to like 5 or 10 files per Map.