Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lua API format #40

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Lua API format #40

wants to merge 2 commits into from

Conversation

oeed
Copy link
Owner

@oeed oeed commented Jan 30, 2016

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.

This was referenced Jan 30, 2016
@oeed oeed added the proposal label Jan 30, 2016
@viluon
Copy link
Collaborator

viluon commented Jan 30, 2016

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

@oeed
Copy link
Owner Author

oeed commented Jan 30, 2016

@viluon Okay, good idea.

@lyqyd
Copy link
Collaborator

lyqyd commented Apr 19, 2016

What obstacles remain before we can accept this proposal?

@viluon
Copy link
Collaborator

viluon commented Apr 20, 2016

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
Copy link
Owner Author

oeed commented Apr 20, 2016

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
Copy link
Collaborator

lyqyd commented Apr 20, 2016

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
Copy link
Owner Author

oeed commented Apr 20, 2016

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants