Implement repository hierarchy

[GoogleCodeExporter]

Rationale:

MS Outlook creates a hierarchy of type-centric folders for storing data in PST 
files. This concept can be extended to support multi-type folders allowing a 
context-centric folder hierarchy.

Design:

 * Inbox - the default folder for incoming items
 * Outbox - pending outgoing items
 * Sent - outgoing items post-processing
 * Deleted - removed items

Original issue reported on code.google.com by benfortuna on 16 Sep 2010 at 5:29

[GoogleCodeExporter]

Possible use GTD to model hierarchy:

http://lifehacker.com/5321180/turn-gmail-into-your-ultimate-gtd-inbox

Original comment by benfortuna on 16 Sep 2010 at 5:59

[GoogleCodeExporter]

For mail, perhaps the following hierarchy makes more sense:

Inbox  - all incoming mail messages (automatic sorting into sub-folders based 
on message rules)

Sent   - all outgoing mail messages (flag indicates if mail is actually 
delivered)

Templates  - like drafts but templates are stored in a separate hierarchy and 
not removed after sending a message

-- below are potential search folders..

Draft  - unsent saved messages (probably a search folder on the Sent hierarchy 
checking the delivery flag)

Deleted  - a search folder on the Inbox hierarchy checking the deleted flag

Archive - a search on Inbox checking the archived flag

Original comment by benfortuna on 12 Apr 2011 at 5:35

[GoogleCodeExporter]

A more generic structure for a Personal Content Repository (PCR) might look 
somethings like this:

 * entities
   - organisation (website, company info)
   - person (contact details, photo, @ref[organisation*])
   - resource (application, server, printer, room, @ref[organisation*])

 * subscriptions
   - email (subject, body, attachments, @ref[email], @ref[entity+])
   - rss feed (title, @ref[entity])
   - manual upload (@ref[entity])
   - some other form of ingestion

 * lifecycles
   - workflow (identify required actions for current state)
   - state (applicable item state)
   - actions (applicable item actions)
   - policies (triggered by actions or state change)

 * annotations
   - flags (item priority)
   - tags (item categorisation)
   - notes (free-form annotations - applied directly to items, not really defined in this hierarchy)

Original comment by benfortuna on 15 Nov 2011 at 5:09

[GoogleCodeExporter]

Context may be another type of hierarchical annotation used to categorise 
entities. eg:

Technology/Hardware
Work/Acme
Social/Family
Software/Open Source/Linux/Ubuntu

For the selected context the filtered results may show items grouped by entity 
types (i.e. people, orgs, resources). 

Activating an entity will show a combined view of subscriptions (mail, rss 
items, files, etc.).

The context breadcrumb should also allow drill-down by sub-context, 
subscription type (mail, rss, etc.), or saved search. eg:

Social/Friends/Mail - subscription type
Technology/Feeds - "

Social/Friends/Joe Bloggs - entity
Technology/Slashdot.org - "

Social/Friends/Address - saved search
Technology/Slashdot.org - "

Original comment by benfortuna on 16 Nov 2011 at 12:06

[GoogleCodeExporter]

Another root folder in the generic structure:

 * files

Store uploaded files using node names generated from a hash (sha/md5, etc.). 
The benefit of a hash is that the same file won't be stored twice - useful in 
cases where lots of duplicates can occur (e.g. photos, music, etc.)

Original comment by benfortuna on 21 Nov 2011 at 6:14

[GoogleCodeExporter]

Prefer deep over wide trees. For large child counts (i.e. files and 
subscriptions) use synthetic hierarchy.

e.g. for files, use the hash to create tree structure from pairs 
(e5/d2/45/d5/..)

Original comment by benfortuna on 22 Nov 2011 at 11:10

[GoogleCodeExporter]

Should subscriptions (e.g. feeds, twitter, etc.) be separated from 
communications (e.g. email, im, etc.)? Probably:

 - entities <-----<-<
 - subscriptions -| <-<-<
 - communications --|-<-<
 - annotations -------| |
 - attachments ---------|

Original comment by benfortuna on 6 Dec 2011 at 11:57