[WIP/Dev] Disk - API for a bukkit filesystem

Disk is a plugin being designed for managing a simple file system (on top of the OS's fs) for bukkit. Players and plugins are the users in the system where both can have their own home folders, belong to permission groups, have disk space quotas, and set their own permissions for their own content. Plugins will also be able to act on behalf of players, and in fact, there will be no in game interface for the plugin (configuration is managed though files). Another plugin will handle the in game interface.

Keep in mind everything is still a work in progress, and any specification is prone to change. Even after the first few releases.

Key points of the Disk plugin:
- Clean separation from interface and implementation
- Resource management in the form of disk space quotas for players and plugins
- Internally stateless as possible
- Security and consistency is emphasized over performance
- Admin controlled permissions of players and plugins though configuration
- Player controlled permissions of their own files/directories
- A permission system for a file system
- The Disk file system implements its own inode files

Some uses: Storing player created content:
Due to the nature of file system permissions, players will be able to have their own permissions set for their own content. And data can be stored per-player as well as per-plugin. The Disk plugin's internal permissions set is a kind of generalization of the usual bukkit permissions. It's not meant to be better, just to be geared more for a permission network. Naturally, admin of the system should be able to have the last say on all permissions, and hopefully I'll be able to have them have highest power inherent from the structure of the file system, so no extra code is required. ie whoever controls a directory has the final say over the child directories, and admin control root itself. Which means they control plugin data folders in the Disk system (should the plugins choose to do so) and they control player directories.

File system structure:

Code:

The file system itself is stored in a directory named after the file system
Admin implies needing root for write-access
File/directory names must only contain alphanumerical values and underscores


[dir] / (admin):
    [dir] plug (admin):
        [dir] Plugin A (admin)
            [file] Plugin file (admin)
            ...
        ...
    [dir] home (admin):
        [dir] Player <name> (admin):
            [dir] Player information (admin):
                [file] Player quota (admin)
                [file] Player group (admin)
                ...
            [dir] Player data (player):
                [file] Player file 1 (player)
                ...
        ...
    
    [dir] Group folder:
        ..
        
    Disk Data folder (admin):
        [file] Disk configuration info (quota size, default player quota ...)

API notes:

Code:

Public API:

All non-file-system calls must pass a directory context (the current working directory)
The directory context is created on behalf of a plugin working for a *Command Sender*

{Return in brace} Call: [parameters in brackets]
(File system commands)
{Report string} Check file system integrity (file system name)
{Success flag}  Create file system (file system name)
{Success flag}  Switch to file system (file system name)
{Success flag}  Remove file system (file system name)
{System name}   Get current file system name
{Success flag}  Set file system parameter (key string, value string)
{String value}  Get file system parameter (key)


(Directory commands)
{Success flag} Create Directory [Directory name]
{Success flag} Remove Directory [Directory name]
{Success flag} Move Directory [old directory, new directory]
{Success flag} Change permissions [directory name, permissions name]
{Success flag} Set Directory quota [directory name]
{Directory quota} Get directory quota [directory name]


(File commands)
{Success flag} Open file for read [file name]
{Success flag} Open file for write [file name]
{Success flag} Open file for append [file name]
{Success flag} Close file [file handle]
{Success flag} Remove file [file handle]
{Success flag} Move file [old file name, new file name]
{Success flag} Change permissions [file name, permissions name]
{Data buffer} Read file [file name]
{Success flag} Write buffer

(Directory Context commands)
{Success flag} Change to directory [directory name]
{Success flag} Display current directory
{File record list} List files and directories

(Group commands)
{Success flag} Create group [group name]
{Success flag} Remove group [group name]
{Group list} List groups
{Player list} List players
{Success flag} Add player [player name]
{Success flag} Remove player [player name]
{Success flag} Add player to group [player name, group name]
{Success flag} Remove player from group [player name, group name]
{Success flag} List players in a group
{Success flag} List groups a player is in
{Success flag} Check if player exists
{Success flag} Check if group exists


Exceptions:
Internal error (thrown when the plugin makes an error, or when the file system is not consistent)
File not found error
Insufficient permissions error
Out Of Allocated Disk Memory error
ParameterException error


File system parameters:
max file system memory allocation
default player memory allocation
default plugin memory allocation
max directory depth



File-record string format:
mode \t owner \t group \t filesize \t filename

 

So basically you're trying to allow players make their own permissions for their own stuff in game... IF a plugin hooks into this, and uses your... interesting system.

EDIT: I honestly don't understand why you're trying to reinvent a file system either.

I've tried reading this a couple times... And yet I still don't completely comprehend what you are trying to accomplish.

 

If a plugin lets users create, manage, and store their own content, this plugin is made to help simplify the process.

For example, let's say there's a simple plugin that lets players copy and paste cubical sections of blocks (shudup, I know world edit already does this ). Well, plugging into a Disk conforming plugin allows the Copy-Paste plugin to just write the copied data to the player's directory with the file name specified by the player. In fact, the players organize their saved models however they want with naming, choose whether or not to let what players/groups access can access their saved data, and admin control how much data a player can use with quotas.

Part of the point is allowing data itself to have permissions control, as opposed to plugin commands. It was actually an accident that trying to implement data permissions was easily extended to having player controlled permissions.
It's not so much to reinvent anything per se as to tie up some common solutions: player persistence, a general data-oriented permission system (which I'll admit is not good as others for the usual who-can-run-what command), a player-managed way to organize saved data, a way for admin to specify memory limits per plugin and per player, and for plugins to work on top of these features with ease and no care on how it's done. The plugin built on top of Disk's API for its own storage shouldn't have to care how about organization, data permissions, or player memory limits.

Sorries if I'm a bit ramblish and incoherent, working back to back morning and night shifts has me a bit tired.



If anything, I plan on making future plugins built on top of my own Disk plugin platform. I wanted to create an in game text editor plugin, and thus why I decided to start on this first.

 

Well keep up the good work! I can't wait to see the final product!

 

Alright, I'll accept that response. It helps me understand it more in any case.