search

oeed / CraftOS-Standards

Community standard file formats, communication systems, etc. for ComputerCraft and CraftOS 2.0
Other
20 stars 16 forks source link

Lua API format #40

Open oeed opened 8 years ago

oeed commented 8 years ago

As discussed in #26 and #18, the Lua format is being split in to separate types.

This format is exclusively for files that are loadable via os.loadAPI. It might be worth also considering what to do with files that are APIs but use some custom API loader or class system. Maybe a miscellaneous Lua format?

Also see: #39 and #41.

viluon commented 8 years ago

I would rather move this standard to CraftOS-Standards/File Formats/Source Code/Lua/.

oeed commented 8 years ago

@viluon Okay, good idea.

lyqyd commented 8 years ago

What obstacles remain before we can accept this proposal?

viluon commented 8 years ago

The proposal defines .api as the API file extension, but states that an API is anything that loads without issues with os.loadAPI. That means that APIs following this standard would have to be accessed like so:

_G[ "myAPI.api" ].foo( "bar" )

I don't think that's intended. Any sane being (no offence @lyqyd, I saw LyqydOS source) would avoid os.loadAPI at all costs. Besides, a standard Lua source loads with os.loadAPI just fine, it actually doesn't have to specify any global variables, and would therefore not be considered an application programming interface at all.

oeed commented 8 years ago

Hmmm that's a good point @viluon. I really wish @dan200 would add support for extensions for os.loadAPI (although for some reason I feel like he has...).

Perhaps .api is the recommended extensions, but no extension is supported.

lyqyd commented 8 years ago

I'm not entirely certain why we're pushing in the direction of everything having a file extension. It makes a lot of sense with pure data files, like nfp, or even table. It doesn't make a lot of sense (within the context of ComputerCraft) for executable files, like lua programs or APIs. It's definitely true that there are blurry lines between programs and APIs especially, given the way they are loaded and run. Can we get away with no file extension on both apis and programs?

oeed commented 8 years ago

@lyqyd the main issue is detecting the MIME. Extensions make it easy. So, if they are going to have different extensions, then ideally, yes, they would have different extensions.

That said, I think in realise people are going to want to have no extension for both, so we'll need to figure out how that should work.