This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
Lyqyd's profile picture

[RFC] Metadata file structure compatible with all file types

Started by Lyqyd, 13 May 2014 - 05:02 PM
Lyqyd #1
Posted 13 May 2014 - 07:02 PM
This RFC is proposed as an alternative system to the metadata RFC recently proposed by AmandaC.

The alternative system I propose is as follows:

A folder named ".meta" will be present in the root of the drive. Any program may create this folder if it is not present, but no program may delete this folder without explicit instruction to do so by the user (for instance, the user running "rm .meta").

Inside this folder, the folder structure present in the rest of the computer will be mirrored for any metadata present. A file named bar in the folder foo (/foo/bar) would have metadata present at "/.meta/foo/bar". The metadata file will be a valid Lua file declaring a number of values. No values are required to be present, but some values must be in the specified format if they are present. Each value is listed in the table below; an example metadata file follows:


Key:          Value:
name          string
author        string
version       string
description   string
icon          table
timestamp     table
type          string

The "icon" table would be formatted with each key of the table being the width and height of the icon image as a string, concatenated from width.."x"..height. The value of each would be a file location. The metadata of those files would be used for file type detection, if applicable.

The timestamp table's keys would be any of the following values: created, modified, accessed. The value would be a standard time stamp format to be determined, but likely including in-game date and time in a string.

An example metadata file:


name = "Awesome Image"
author = "oeed"
type = "sketch"
timestamp = {
  accessed = "2, 12:45",
  modified = "1, 9:32",
  created = "1, 9:28",
}

Timestamp values are using an arbitrary format and do not constitute a formal proposal.

Here is an example function to parse a metadata file, given an exact path to the file. As you can see, storing the metadata as both a human-readable file and a valid Lua file has distinct advantages. Note that to maintain human-readability, textutils.serialize is not an option, due to its behavior on pre-1.6 versions of ComputerCraft. This function returns a table, where each key is one of the metadata attributes (name, version, description, etc.) and the values are the values declared in the metadata file:


function parseMeta(metaPath)
  if fs.exists(metaPath) then
    local handle = fs.open(metaPath, "r")
    if handle then
      local data = {}
      local fn, err = loadstring(handle.readAll())
      handle.close()
      if fn then
        setfenv(fn, data)
        local success, err = pcall(fn)
        if success then
          return data
        else
          return nil, err
        end
      else
        return nil, err
      end
    else
      return nil, "could not read metadata"
    end
  else
    return nil, "no metadata found"
  end
end

Obviously, getting the metadata for a file using the file's path is a simple matter:


function getMetadataForFile(path)
  return parseMeta(fs.combine(".meta", path))
end

To build a comprehensive table of metadata for all files on the computer, we simply need another pair of functions. The below functions implement a recursive solution, using a worker function to get all of the metadata for each file in a folder, and another function to correctly initialize the first function.


local function getMetadataForFolder(folderPath, metadata)
  if not metadata then metadata = {} end
  for _, file in ipairs(fs.list(folderPath)) do
    local path = fs.combine(folderPath, file)
    if fs.isDir(path) then
      getMetadataForFolder(path, metadata)
    else
      metadata[path] = parseMeta(path)
    end
  end
  return metadata
end

function getAllMetadata()
  if fs.exists(".meta") and fs.isDir(".meta") then
    return getMetadataForFolder(".meta")
  else
    return nil, "no metadata available"
  end
end

As you can see, the above two functions only iterate the files in the .meta folder to avoid extra file existence checks. If desired, the parseMeta function could be switched out for the getMetadataForFile function and an exception made to ignore the .meta folder when looking for files to check metadata on.

Packed metadata (for file transmission purposes) can be handled by packing the metadata in whatever format is desired and providing an unpacking function at the top of the file. If present, an unpacking function will be preceded by the comment "–@start unpack" and followed by the comment "–@end unpack". This function will be loaded into an environment including all built-in APIs and the current shell, and executed with one parameter: the full path of the file. This will allow the file to write its own metadata file and self-modify to remove the unpacking function if desired.
zekesonxx #2
Posted 13 May 2014 - 07:23 PM
You really thought this through didn't you?
I would think it would make the most sense to have the timestamps be UTC Unix timestamps, although I'm not sure if you can get those in CC's APIs without an external source (ie a web server)
Lyqyd #3
Posted 13 May 2014 - 07:47 PM
A utc-style timestamp would be useful, but any genuine utc timestamps would require an external data source. Maybe there is an easy way to construct and decode a similar sort of numeric-only timestamp based on the minecraft world date and time.
apemanzilla #4
Posted 13 May 2014 - 07:50 PM
Sorry, but wouldn't it be better to save icons as nested tables? It would allow you to iterate through the individual columns or rows more easily…
Lyqyd #5
Posted 13 May 2014 - 08:03 PM
That's certainly a viable alternative. Both approaches have advantages and disadvantages. I do like the flat table approach, but two dimensional tables would be nice too. I don't think that iterating individual columns and rows would be done all that commonly, though. It seems more likely that one would want to look up a specific dimension set. The two-dimensional table does mean that that sort of lookup requires extra steps (you have to make sure the width table exists before indexing the width and length), so there are advantages both ways. I feel like looking up specific dimensions would be a more common task than iterating the entire table, so I suggested the flat table way.
apemanzilla #6
Posted 13 May 2014 - 08:15 PM
That's certainly a viable alternative. Both approaches have advantages and disadvantages. I do like the flat table approach, but two dimensional tables would be nice too. I don't think that iterating individual columns and rows would be done all that commonly, though. It seems more likely that one would want to look up a specific dimension set. The two-dimensional table does mean that that sort of lookup requires extra steps (you have to make sure the width table exists before indexing the width and length), so there are advantages both ways. I feel like looking up specific dimensions would be a more common task than iterating the entire table, so I suggested the flat table way.
True. Also, how do you intend to get the height and width of the icons in flat form? Iterate over each item finding the maximum? With a 2D array it would be as simple as

local w,h = #icon, #icon[1]

Maybe it would be best to support both methods. I'd be willing to write a couple intermediate methods to unify it all into methods like icon:getPixel(1,2) or icon:getWidth().
Lyqyd #7
Posted 13 May 2014 - 08:35 PM
Hmm. Supporting both formats adds significant complexity for trivial benefits. I'm not a fan of the using-both idea. The 2D array wouldn't work with the # shortcut, since it would be a sparse matrix and those shortcuts require a contiguous array-style table. One or the other of the two ways of doing it will have to be picked. They're both going to require iterating the table with a pairs() loop to look at every entry, of course. The two-dimensional method requires a (second) nested pairs loop as well, whereas the flat table way requires a string.match to pull dimensions out of the key. I'm fine with either way, but the flat table method definitely seems easier to me. Further thoughts? Anybody else have an opinion on flat vs. 2D for the icons?
apemanzilla #8
Posted 15 May 2014 - 02:39 AM
I'll let you choose since it's your idea :P/>

Additionally, how will file transfers be handled? (copying to a disk and then to another computer, uploading to pastebin, etc) With a disk you could just stick a .meta folder on the disk and hope the receiving end knows how to use it, but with pastebin it's not so easy…
oeed #9
Posted 15 May 2014 - 03:38 AM
I quite like this idea, I might try to implement it in OneOS 1.2.


Any possibility of an API to do this, or is it something we need to make ourselves?
theoriginalbit #10
Posted 15 May 2014 - 03:51 AM
wait, what is `type` is it `program` vs `api`, or?
oeed #11
Posted 15 May 2014 - 04:05 AM
wait, what is `type` is it `program` vs `api`, or?

Based on the example I'd say it's the file type. So for example a .xls file would have the type 'excelspreadsheet' (or something like that).

I'd also say we need a table of these types, as some people may use other names.

So maybe something like, 'plaintext' for .txt and .text documents, and 'luacode' for .lua files.

Or something like that.


On the subject of timestamps, I feel that a table would be better (so '13:45, Day 1' would be {13, 45, 1}, maybe not that order though. Otherwise you'll have to parse the string. In the case of OneOS, I don't want it to be too slow when browsing files.

Also, how to you propose writing changes?
apemanzilla #12
Posted 15 May 2014 - 04:36 AM
wait, what is `type` is it `program` vs `api`, or?

Based on the example I'd say it's the file type. So for example a .xls file would have the type 'excelspreadsheet' (or something like that).

I'd also say we need a table of these types, as some people may use other names.

So maybe something like, 'plaintext' for .txt and .text documents, and 'luacode' for .lua files.

Or something like that.


On the subject of timestamps, I feel that a table would be better (so '13:45, Day 1' would be {13, 45, 1}, maybe not that order though. Otherwise you'll have to parse the string. In the case of OneOS, I don't want it to be too slow when browsing files.

Also, how to you propose writing changes?

Maybe for filetypes, we can have a GitHub repo that has a file detailing each extension and their names:

{
  ["xls"] = {
    "excelspreadsheet",
    "ExcelSpreadsheet",
    "spreadsheet"
  },
  ["nfp"] = {
    "image",
    "paintimage"
  },
  ["txt"] = {
    "plaintext",
    "text"
  },
  ["lua"] = {
    "luacode",
    "code",
    "program"
  }
It would allow users to submit a PR or issue if they want a file type added for their files, and OSes could update the file from HTTP on boot or something along those lines.

If we wanted, we could even add default icons for each extension to the table structure if the OS doesn't know what to use.

For timestamps:

Generating:

local timestamp = 24 * os.day() + os.time()

Parsing for day:

local day = math.floor(timestamp / 24)

Parsing for time:

local time = timestamp % 24

This would be fast, efficient and work nearly everywhere I can think of. You obviously wouldn't want to send timestamp data across worlds, but this is the easiest non-HTTP system.
Edited on 15 May 2014 - 02:44 AM
oeed #13
Posted 15 May 2014 - 05:27 AM
Maybe for filetypes, we can have a GitHub repo that has a file detailing each extension and their names:

{
  ["xls"] = {
	"excelspreadsheet",
	"ExcelSpreadsheet",
	"spreadsheet"
  },
  ["nfp"] = {
	"image",
	"paintimage"
  },
  ["txt"] = {
	"plaintext",
	"text"
  },
  ["lua"] = {
	"luacode",
	"code",
	"program"
  }
It would allow users to submit a PR or issue if they want a file type added for their files, and OSes could update the file from HTTP on boot or something along those lines.

If we wanted, we could even add default icons for each extension to the table structure if the OS doesn't know what to use.

For timestamps:

Generating:

local timestamp = 24 * os.day() + os.time()

Parsing for day:

local day = math.floor(timestamp / 24)

Parsing for time:

local time = timestamp % 24

This would be fast, efficient and work nearly everywhere I can think of. You obviously wouldn't want to send timestamp data across worlds, but this is the easiest non-HTTP system.

Yea, I like the GitHub idea. If I end up adding this to OneOS before someone else creates an API I'll make something like that.

Putting the time in a single number is a good idea too.

In OneOS in terms of showing time modified, I'll probably convert it to a real timeago. (So, for example, if it was made 1 hour ago of in game time I'll show 'A minute ago' (or what ever the actual time is))
apemanzilla #14
Posted 15 May 2014 - 06:07 AM
– snip –

Yea, I like the GitHub idea. If I end up adding this to OneOS before someone else creates an API I'll make something like that.

Putting the time in a single number is a good idea too.

In OneOS in terms of showing time modified, I'll probably convert it to a real timeago. (So, for example, if it was made 1 hour ago of in game time I'll show 'A minute ago' (or what ever the actual time is))
Hmm.. Would be possible, but likely inaccurate. You have to remember time isn't measured in seconds, but ticks - TPS drops, then the readings are off. If you want to do that, you'd probably be best off using real-world time.

I don't think we're quite ready for an API yet - we still have to figure out things like saving icons, icon image formats, keys and what they mean, etc.
Edited on 15 May 2014 - 04:16 AM
oeed #15
Posted 15 May 2014 - 07:24 AM
Hmm.. Would be possible, but likely inaccurate. You have to remember time isn't measured in seconds, but ticks - TPS drops, then the readings are off. If you want to do that, you'd probably be best off using real-world time.

I don't think we're quite ready for an API yet - we still have to figure out things like saving icons, icon image formats, keys and what they mean, etc.

I suppose you're right about the TPS issue, although it's better to be off by a bit than not be able to know when it was made at all. A real world time solution would be a lot better if it weren't for the issue of playing without internet.

Oh I know it's not ready for an API yet, I'm more wondering if someone else is considering to make one.
apemanzilla #16
Posted 15 May 2014 - 01:54 PM
– snip –

I suppose you're right about the TPS issue, although it's better to be off by a bit than not be able to know when it was made at all. A real world time solution would be a lot better if it weren't for the issue of playing without internet.

Oh I know it's not ready for an API yet, I'm more wondering if someone else is considering to make one.
The thing with using the in-game time is that usually servers tend to slow down to 10-15 tps over time, which means that your readings would quickly end up very far off.

On the topic of an API, I'd be happy to help write one for public use.
Lyqyd #17
Posted 15 May 2014 - 03:40 PM
I'll let you choose since it's your idea :P/>

Additionally, how will file transfers be handled? (copying to a disk and then to another computer, uploading to pastebin, etc) With a disk you could just stick a .meta folder on the disk and hope the receiving end knows how to use it, but with pastebin it's not so easy…

Well, if it comes down to it, let's stick with the flat table format for icons for now.

I quite like this idea, I might try to implement it in OneOS 1.2.


Any possibility of an API to do this, or is it something we need to make ourselves?

I'll probably put an API repo up on github for this, which everyone is welcome to contribute to. It will be relatively generic, mostly dealing with storing and retrieving the metadata. I will probably also work on a very simple fs override that implements automatic updating of the metadata using that API.

wait, what is `type` is it `program` vs `api`, or?

Type is intended to be a short, one-word string that unambiguously describes the format of the file contents; formats such as "text", "lua", "nfp", "nfa", "paint", etc.

Also, how to you propose writing changes?

I'm not sure what you're asking here. Could you clarify the question?

For timestamps:

Generating:

local timestamp = 24 * os.day() + os.time()

Parsing for day:

local day = math.floor(timestamp / 24)

Parsing for time:

local time = timestamp % 24

This would be fast, efficient and work nearly everywhere I can think of. You obviously wouldn't want to send timestamp data across worlds, but this is the easiest non-HTTP system.

That's a pretty reasonable timestamp format, nice and compact.
CometWolf #18
Posted 15 May 2014 - 03:51 PM
The two-dimensional table does mean that that sort of lookup requires extra steps (you have to make sure the width table exists before indexing the width and length), so there are advantages both ways.
There's a quick way around this which i use for Turtle Architect, metatables! Seeing as the information is retrieved by executing the file as a code anyways, it wouldn't be that hard to implement.

icon = setmetatable(
  {
    [1] = {1,2,3} -- you get the point
  },
  {
    __index = function(t,k)
	  t[k] = {}
	  return t[k]
    end
  }
)
As you might've gussed, i'd prefer 2D tables. Makes it easier to process in my opinion if the values are just numbers. Idk what would be lightest computation wise, but maybe we should find out?
Tiin57 #19
Posted 15 May 2014 - 10:12 PM
Why not use HTTP mime-type things? (Can't remember what they're called, but those "text/html" and "application/lua" strings in HTTP headers.)
oeed #20
Posted 15 May 2014 - 10:43 PM
Also, how to you propose writing changes?

I'm not sure what you're asking here. Could you clarify the question?

Well, when, for example, someone modifies the document and you need to change the modified date. It's just not the easiest format to allow editing really.

Why not use HTTP mime-type things? (Can't remember what they're called, but those "text/html" and "application/lua" strings in HTTP headers.)
That'd actually make more sense, so you can do things like image/nfp etc.


Also, I was thinking that it'd probably best best if part of the API was an fs API wrapper. So essentially every time you used things such as fs.open it wouild change/create the meta data file.
AmandaC #21
Posted 15 May 2014 - 11:09 PM
I still feel that our two protocols aren't mutually exclusive, however some notes:

  • The .meta structure can make no sense if a disk is removed, and a new one is added in it's place. Perhaps a way to mitigate this would be to have disks have their own .meta under their own trees.
  • +1 for MIME-based type information, instead of arbitrary words
  • That said, perhaps what you could do is specify some top-level types, such as "program", "file", "image", etc, that narrows it down more than a MIME type could given no context.
  • Meta-data such as the image's dimensions might be a good idea. (Obv. only for image files.)

That said, I will definately use this format in some capacity for my highbeam indexer suite, even if it's just a read-only virtual FS. Standards for data access are good. :)/>
apemanzilla #22
Posted 15 May 2014 - 11:21 PM
Also, how to you propose writing changes?

I'm not sure what you're asking here. Could you clarify the question?

Well, when, for example, someone modifies the document and you need to change the modified date. It's just not the easiest format to allow editing really.

Why not use HTTP mime-type things? (Can't remember what they're called, but those "text/html" and "application/lua" strings in HTTP headers.)
That'd actually make more sense, so you can do things like image/nfp etc.


Also, I was thinking that it'd probably best best if part of the API was an fs API wrapper. So essentially every time you used things such as fs.open it wouild change/create the meta data file.
I've been (slowly) working on a VFS API which pretty much lets you overwrite any fs call you want…
I still feel that our two protocols aren't mutually exclusive, however some notes:

  • The .meta structure can make no sense if a disk is removed, and a new one is added in it's place. Perhaps a way to mitigate this would be to have disks have their own .meta under their own trees.
  • +1 for MIME-based type information, instead of arbitrary words
  • That said, perhaps what you could do is specify some top-level types, such as "program", "file", "image", etc, that narrows it down more than a MIME type could given no context.
  • Meta-data such as the image's dimensions might be a good idea. (Obv. only for image files.)

That said, I will definately use this format in some capacity for my highbeam indexer suite, even if it's just a read-only virtual FS. Standards for data access are good. :)/>/>/>

Even better MIME types:
program/api
image/sketch
image/nppanimation
text/plain
text/ink

And so on
Edited on 15 May 2014 - 09:24 PM
oeed #23
Posted 15 May 2014 - 11:26 PM
Also, I was thinking that it'd probably best best if part of the API was an fs API wrapper. So essentially every time you used things such as fs.open it wouild change/create the meta data file.
I've been (slowly) working on a VFS API which pretty much lets you overwrite any fs call you want…

Well, a VFS API is a bit overkill really. All you'd need to do it have something like this (pseudo code obviously)


local _fs = fs
fs.open = function(path, mode)
  if mode == 'w' then
    if _fs.exists(path) then
      meta.setModifiedTime(path, theTime) --just an example name
    else
      meta.setCreatedTime(path, theTime)
    end
  elseif mode == 'r' and _fs.exists(path) then
    meta.setOpenedTime(path, theTime)
  end
  _fs.open(path, mode)
end
Edited on 15 May 2014 - 09:27 PM
apemanzilla #24
Posted 16 May 2014 - 12:19 AM
Also, I was thinking that it'd probably best best if part of the API was an fs API wrapper. So essentially every time you used things such as fs.open it wouild change/create the meta data file.
I've been (slowly) working on a VFS API which pretty much lets you overwrite any fs call you want…

Well, a VFS API is a bit overkill really. All you'd need to do it have something like this (pseudo code obviously)


local _fs = fs
fs.open = function(path, mode)
  if mode == 'w' then
	if _fs.exists(path) then
	  meta.setModifiedTime(path, theTime) --just an example name
	else
	  meta.setCreatedTime(path, theTime)
	end
  elseif mode == 'r' and _fs.exists(path) then
	meta.setOpenedTime(path, theTime)
  end
  _fs.open(path, mode)
end
Well, the point was I already have it started :P/>
Lyqyd #25
Posted 16 May 2014 - 01:35 AM
There's a quick way around this which i use for Turtle Architect, metatables! Seeing as the information is retrieved by executing the file as a code anyways, it wouldn't be that hard to implement.

icon = setmetatable(
  {
	[1] = {1,2,3} -- you get the point
  },
  {
	__index = function(t,k)
	  t[k] = {}
	  return t[k]
	end
  }
)
As you might've gussed, i'd prefer 2D tables. Makes it easier to process in my opinion if the values are just numbers. Idk what would be lightest computation wise, but maybe we should find out?

I'm very much not a fan of doing things this way. Having to add boilerplate metatable declarations to every icon table just does not appeal at all. Without this, all of the data stored in the metadata file pertains specifically to that file.

Why not use HTTP mime-type things? (Can't remember what they're called, but those "text/html" and "application/lua" strings in HTTP headers.)

I like the mime-style file type designations idea.

Also, how to you propose writing changes?

I'm not sure what you're asking here. Could you clarify the question?

Well, when, for example, someone modifies the document and you need to change the modified date. It's just not the easiest format to allow editing really.

Also, I was thinking that it'd probably best best if part of the API was an fs API wrapper. So essentially every time you used things such as fs.open it wouild change/create the meta data file.

Yes, one of the two APIs I intend to write for this is a very small fs API replacement/wrapper that manages the metadata files and keeps them updated.

I still feel that our two protocols aren't mutually exclusive, however some notes:
  • The .meta structure can make no sense if a disk is removed, and a new one is added in it's place. Perhaps a way to mitigate this would be to have disks have their own .meta under their own trees.
  • +1 for MIME-based type information, instead of arbitrary words
  • That said, perhaps what you could do is specify some top-level types, such as "program", "file", "image", etc, that narrows it down more than a MIME type could given no context.
  • Meta-data such as the image's dimensions might be a good idea. (Obv. only for image files.)
That said, I will definately use this format in some capacity for my highbeam indexer suite, even if it's just a read-only virtual FS. Standards for data access are good. :)/>

I agree! Image dimension metadata is a useful idea.

Even better MIME types:
program/api
image/sketch
image/nppanimation
text/plain
text/ink

And so on

I think yet better ones would be:


lua/program
lua/api
lua/data
text/plain
text/rich
image/sketch
image/nfp
image/nfa
image/paint

Obviously, it isn't an exhaustive list, but it does indicate what sort of data a file contains, and how it is intended to be used, or what the format is.

Well, the point was I already have it started :P/>

There's no problem with building this functionality into existing APIs, but I will still be building an fs replacement/wrapper that only does metadata management, without additional cruft.
oeed #26
Posted 16 May 2014 - 02:26 AM

lua/program
lua/api
lua/data
text/plain
text/rich
image/sketch
image/nfp
image/nfa
image/paint
image/nfp and image/paint are identical. You probably meant image/nft. I think avoiding duplicate MIME types (e.g. image/paint & image/nft) would be a good idea.

Also, may as well add a few to the list:


text/ink
package/pkg -- or package/oeed, but I'm not aware of any others using .pkg in CC

I think folders will also need to be able to have file types. In OneOS programs are folders with the extension .program

Maybe something like

bundle/oneosprogram


Will there be something that checks all the files and assigns a file type if it doesn't have one based on it's extension or file content (most paint images won't have an extension, Sketch scans the content and detects what type it is).
Edited on 16 May 2014 - 01:31 AM
awsmazinggenius #27
Posted 16 May 2014 - 03:27 AM
Don't OneOS programs have a folder with a .program extension, not a .folder extension? Or do both work?
oeed #28
Posted 16 May 2014 - 03:31 AM
Don't OneOS programs have a folder with a .program extension, not a .folder extension? Or do both work?

Yes, sorry, typo. It's just .program
Lyqyd #29
Posted 16 May 2014 - 03:35 AM
Here's the github repo with my initial work on the API and fs replacement.

I'm not sure about the package and bundle mime top level types. There's probably a better way to do that than adding two top-level types for just those specific things, but I'm really not sure what it would be yet.
oeed #30
Posted 16 May 2014 - 04:02 AM
Here's the github repo with my initial work on the API and fs replacement.

I'm not sure about the package and bundle mime top level types. There's probably a better way to do that than adding two top-level types for just those specific things, but I'm really not sure what it would be yet.

Maybe have a generic/miscellaneous top-level.


other/pkg
other/oneosprogram
skwerlman #31
Posted 16 May 2014 - 08:24 AM
Here's the github repo with my initial work on the API and fs replacement.

I'm not sure about the package and bundle mime top level types. There's probably a better way to do that than adding two top-level types for just those specific things, but I'm really not sure what it would be yet.

Maybe have a generic/miscellaneous top-level.


other/pkg
other/oneosprogram
Perhaps something like:

folder/folder
folder/pkg
folder/oneosprogram
folder/os – would be used by bootloaders to mark folders containing OSes
folder/meta – denotes folders that, like .meta, contain metadata and shouldn't be deleted

EDIT: 100th post! Woo!
Edited on 16 May 2014 - 09:56 PM
oeed #32
Posted 16 May 2014 - 08:42 AM
Perhaps something like:

folder/folder
folder/pkg
folder/oneosprogram
folder/os – would be used by bootloaders to mark folders containing OSes
folder/meta – denotes folders that, like .meta, contain metadata and shouldn't be deleted

Hmm, having that many for folders seems a little overkill. It could work though.
.pkg files aren't folders, so you'd still need another thing for it.

Also, what if the file extension doesn't have a file type.
I'm thinking of an unknown/abc type thing, but it's not ideal.

File types would need to be 99% reliable too, if I do adopt this in OneOS then I'll change from extension based file icon name to file type based names.
Edited on 16 May 2014 - 06:44 AM
Lyqyd #33
Posted 16 May 2014 - 05:50 PM
I think an "archive" top-level type name would be valuable, so archive/pkg. I don't think folder types are necessary, particularly. I'd be interested in hearing some good justification for them, though.

I need to update the github repo to handle metadata in disks and such, which I just remembered this morning. I'd be interested in hearing any feedback on the metadata API as it stands currently.
apemanzilla #34
Posted 16 May 2014 - 07:28 PM
I think an "archive" top-level type name would be valuable, so archive/pkg. I don't think folder types are necessary, particularly. I'd be interested in hearing some good justification for them, though.

I need to update the github repo to handle metadata in disks and such, which I just remembered this morning. I'd be interested in hearing any feedback on the metadata API as it stands currently.
Also, someone (can't remember just who :/) made a .tar utility that can open tar files, so archive/tar could be useful too.
skwerlman #35
Posted 16 May 2014 - 11:55 PM
I don't think folder types are necessary, particularly. I'd be interested in hearing some good justification for them, though.
I think that a folder type would be useful for OSes to mark executable folders, so they can more easily determine whether a folder should be opened versus run (maybe folder/executable instead of folder/oneosprogram?).
It would also allow for OSes to 'protect' folders so that they require confirmation to edit any contained files (e.g. OneOS's System folder). This is similar to requiring Admin to edit files in C:\Windows or needing root to edit files outside of /home/ on Linux. This way, rather than have an additional file listing protected files, you set a folder to something like folder/protected, and all files/subfolders are treated as though they too are protected.
Also, it would allow for bootloaders to detect OSes without requiring a specific format. Instead of having a folder 'os', a bootloader would simply search .meta for 'folder/os'.
Finally, it makes protecting the .meta folder easier, since it can be marked as 'folder/.meta', which a shell could explicitly ignore (i.e. trying to open .meta from the shell returns 'File not found' or some such). This way, the only way to edit/delete the .meta folder would be to type 'rm .meta' in the vanilla shell.

I think an "archive" top-level type name would be valuable, so archive/pkg. I don't think folder types are necessary, particularly. I'd be interested in hearing some good justification for them, though.

I need to update the github repo to handle metadata in disks and such, which I just remembered this morning. I'd be interested in hearing any feedback on the metadata API as it stands currently.
Also, someone (can't remember just who :/) made a .tar utility that can open tar files, so archive/tar could be useful too.
I agree. There're several archivers out there, so an archive type would be useful.
Lyqyd #36
Posted 17 May 2014 - 01:14 AM
Folders are not executable, so marking folders as executable makes literally no sense whatsoever. Metadata isn't going to be used for permissions, as that is a whole other can of worms and would be better accomplished through other methods. The bootloader/os detection bit could be done just as easily other ways, and a shell that's aware of .meta enough to read it looking for information is aware of it enough to not need to read it to know to ignore it.
columna1 #37
Posted 17 May 2014 - 02:34 AM
I think an "archive" top-level type name would be valuable, so archive/pkg. I don't think folder types are necessary, particularly. I'd be interested in hearing some good justification for them, though.

I need to update the github repo to handle metadata in disks and such, which I just remembered this morning. I'd be interested in hearing any feedback on the metadata API as it stands currently.
Also, someone (can't remember just who :/) made a .tar utility that can open tar files, so archive/tar could be useful too.

That was me!
skwerlman #38
Posted 17 May 2014 - 02:47 AM
Folders are not executable, so marking folders as executable makes literally no sense whatsoever. Metadata isn't going to be used for permissions, as that is a whole other can of worms and would be better accomplished through other methods. The bootloader/os detection bit could be done just as easily other ways, and a shell that's aware of .meta enough to read it looking for information is aware of it enough to not need to read it to know to ignore it.
Executable folders: I was referring to folders that are designed to be treated as programs, like OneOS's setup ('foo.program').

Bootloader/os detection: I don't really think that having to write extra code to detect OSes is good when it can be done easily with existing infrastructure. I guess it comes down to how inclusive we're going to be regarding default types. Maybe instead of adding default support for it, there could be a function in the API to add new file/folder types that aren't supported, so OSes/bootloaders/shells could add types unique to them.

Permissions: Fair enough.
oeed #39
Posted 17 May 2014 - 03:06 AM
Well I don't think an entire category for executable folders needs to be made, just a misc category.

I think meta data for bootloaders is really unnecessary really, no one uses bootloaders anyway.
oeed #40
Posted 24 May 2014 - 01:28 PM
Anyone got any progress on this? I'd like to add it in OneOS 1.2 which is pretty much ready now.
Lyqyd #41
Posted 24 May 2014 - 09:55 PM
I think the main thing that the demo code needs is to have code added to treat disks correctly (a .meta folder on the disk for the disk's files), but beyond that, the fs replacement and metatable API would be ready to be used as drop-in solutions, if desired. I haven't seen any real feedback on the code so far, that I can recall.
awsmazinggenius #42
Posted 25 May 2014 - 12:56 AM
One big flaw I see with this is that if it is a program, it needs to be run first to set it's own metadata to lua/program, if, for example, a user added a program using Finder (that's Windows Explorer for you PC folks) directly into the computers fs without also creating the metadata. If the OS relied purely on .meta, it would encounter issues, as the program would need to be run first, then it could set its own metadata. I'm comparing this to AmandaC's method, which relies on Lua comments at the top of files, which doesn't need code to be run first.
Lyqyd #43
Posted 25 May 2014 - 09:10 AM
I've updated the sample code on github to look for .meta folders on disks and use those. The OS would be responsible for dealing with disk insertion/ejection events to update the metadata list.
MKlegoman357 #44
Posted 01 June 2014 - 09:43 PM
How about default metadata being created not by a function inside a file, but rather with tags AmandaC suggested?

I'm talking about these kind of tags:

--@name My Awesome Hello World program
--@author MKlegoman357
--@description prints 'Hello World!' using a random color.

term.setTextColor(math.random(1, 14) ^ 2)
print("Hello World!")

I think that would be easier for people to use the metadata system. It wouldn't scare young coders too, it looks nicer and is more readable.
Edited on 01 June 2014 - 07:43 PM
Lyqyd #45
Posted 08 November 2014 - 08:07 PM
I've corrected a minor issue in the demo code, so that it will correctly use disk.getMountPath for non-hdd, non-rom drives names. This also allows OSs or fs modifications to use fs.getDrive and disk.getMountPath in conjunction to ensure that .meta folders are placed in the correct locations for all mounted storage media. For instance, LyqydOS uses these functions to ensure that mounted rednet shares or RAID volumes will have their metadata written to that device, to ensure the integrity of the metadata.
powerboat9 #46
Posted 29 August 2015 - 05:59 AM
wait, what is `type` is it `program` vs `api`, or?

Based on the example I'd say it's the file type. So for example a .xls file would have the type 'excelspreadsheet' (or something like that).

I'd also say we need a table of these types, as some people may use other names.

So maybe something like, 'plaintext' for .txt and .text documents, and 'luacode' for .lua files.

Or something like that.


On the subject of timestamps, I feel that a table would be better (so '13:45, Day 1' would be {13, 45, 1}, maybe not that order though. Otherwise you'll have to parse the string. In the case of OneOS, I don't want it to be too slow when browsing files.

Also, how to you propose writing changes?

Perhaps you should use MIME types (text/plain, text/html) for some of them.
Lyqyd #47
Posted 29 August 2015 - 06:23 PM
Yeah, that is what was agreed upon.
Selim #48
Posted 18 January 2016 - 04:47 PM
Am I the only one having problems with this? All I should have to do is just load the two API's and go right? I keep getting the error
[string "disk"]:3: Expected string
on boot.
If I go on a clean system and load each api, first metadata then the fs wrapper, I get
[string "shell"]:109: attempt to call field 'combine' (a nil value)
after loading each and attempting to run "ls".
Edited on 18 January 2016 - 03:50 PM
wilcomega #49
Posted 19 January 2016 - 01:23 PM
i support this idea, we might finnaly be able to have more info about files!
Lyqyd #50
Posted 19 January 2016 - 05:44 PM
Am I the only one having problems with this? All I should have to do is just load the two API's and go right? I keep getting the error
[string "disk"]:3: Expected string
on boot.
If I go on a clean system and load each api, first metadata then the fs wrapper, I get
[string "shell"]:109: attempt to call field 'combine' (a nil value)
after loading each and attempting to run "ls".

I have a working version that I'm using with LyqydOS, so I'll check out the code associated with this post and verify correctness.
Selim #51
Posted 01 February 2016 - 11:00 PM
I have a working version that I'm using with LyqydOS, so I'll check out the code associated with this post and verify correctness.

Did you learn anything?

EDIT: I think it has something specifically to do with Mimic. That is what I am currently using, and I am thinking that the disk API might be weird as it doesn't exactly support disks.

EDIT2: Confirmed. It has something to do with Mimic or at least the version of CC that Mimic uses. CCEmu-Redux does much better. I will attempt on making a local fix.
Edited on 01 February 2016 - 10:51 PM
Lyqyd #52
Posted 02 February 2016 - 01:18 AM
Sorry, forgot to actually sit down and check it out. As long as you're using the two files from the github repo, that's exactly what LyqydOS uses. I do muck about with the disk API a little bit, if I recall correctly, to make metadata work correctly on virtual mounts (if I do, it's in the `env` file in LyqydOS). Obviously, I can't account for emulators misbehaving. :)/>
Selim #53
Posted 02 February 2016 - 01:48 AM
–snip–
Alright, I guess if I cannot find a fix in Mimic, I will add a check in Northbridge Terminal OS to not load the metadata & fs wrapper if running in Mimic.