Support attachments

[jbone]

Placeholder: need to be able to upload / attach arbitrary attachments.

[pjz]

What's the URL space for attachments look like? Using something like /room/pagename/attachments means effectively disallowing slashes in room names.

[jbone]

I think we need either (a) a general collection e.g. /items or /objects, and or (b) a file / attachment specific collection, e.g. /files.

We should be doing name mapping, generally, rather than forcing the "contains" hierarchy into the URL-space. (It seems unmeteor-like and as you note impairs subpages / places constraints on other forms of naming...)

[pjz]

Should they be versioned themselves, or part of a room that's versioned? Would there be a reason for, for example, a room to point to multiple versions of an attachment? or is the single latest version all that's needed?

[jbone]

I think they should be stored by hash and linked by hash, with the name maintained as metadata. Then versioning the page is sufficient; if a new attachment is added, a new version of the page is created with a list of the current attachment hashes?

[pjz]

so they're stored (unversioned) as /data/<hash>, with links to them in pages ? How does access control to them work? Maybe they go under /data/<pagename>/<hash> and inherit <pagename>'s access controls? behind the scenes we can de-dup.

[jbone]

Yeah, that works

On Sep 24, 2015, at 10:19, Paul Jimenez notifications@github.com wrote:

so they're stored (unversioned) as /data/, with links to them in pages ? How does access control to them work? Maybe they go under /data// and inherit 's access controls?

— Reply to this email directly or view it on GitHub.

[pjz]

Note that RESTful stuff was punted in favor of just using CollectionFS. Implemented in https://github.com/grupoarc/grouphug/commit/0eb84a2e8ace3c1f309b07d77b9dbd6c1e1e3f2c.