Complex files

Registered by Mathijs Henquet

This blueprint has been superseded. See the newer blueprint "Simplified Packaging - Managing Content" for updated plans.

I wanted to explore extra functionality that marlin can offer on top of the ususual file managers. The idea I had for quite some time is that a file can have multiple parts and functionalities coupled to it's self. This way the file becomes like a object (OOP) instead of just some binary information.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Superseded
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Sergey "Shnatsel" Davidoff

Related branches

Sprints

Whiteboard

This is just my crazy idea, i dont know it if its such a great one. For example, it might be too complex for non programmers. I still wanted to share it though. Please let me know what you think and what could be improved. And if you have a crazy file managing paradimes feel free to open a blueprint ;)

# Outline
Allow me to illustrate this with a example.

Probably the best example where this would help is with latex files. A latex document consists of a few files. You have the latex source code, images and a pdf output. With the current paradime this forces you to either have all those files in the same directory with other files, causing clutter. Or create a dedicated folder, which is a akward solution. You need a document, adding a folder makes the workflow complexer.

First of all let's define what these files mean. The pdf file is the view, it should be viewable from the outside of the file. In OOP terms it should be a public member. The latex is the source, the thing you edit if you want to change the file, another public member. The images however should *not* be accesable externaly, they are just used for internal file creation. Those are private members in OOP lingo.

If we where to put those things in a complex file, the complex file should represents both 'parts' of the latex document. The different files are seperated by there type/extension now. There is however a better way. The pdf and latex file both also represent a action, edit for latex and view for pdf. Giving the diffrent files a action rather then a type also solves the issue for complex files containing two public members with the same type.

The different actions contained in the complex file should be listed by the file manager, there should also be a way of defining a default action, which could be view for a latex document.

# How do we translate this concept to the current fs?

Proposition (latex file example):
+ Report // a folder, this is the actual complex file
|- .meta // file containing meta data such as default action
|- .view.pdf // files follow format {name}.{action}.{type}, this file is a public member has the action 'view'
|- .edit.latex // action 'edit'
|- image1.jpg // just normal files, private members
|- image2.jpg

Note: .view.pdf and .edit.latex should not be hidden, I realize .* hides a file, probably we will need another metacharacter to define a public member.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.