We need more API/function ideas

[dmarcuse]

See title

[skwerlman]

Maybe a graph API, sort of like the one in OpenCCSensors, but not requiring the mod? (Check their license, we might be able to copy-paste)

[SuicidalSTDz]

Here is my suggestion, let's put all of our ideas for APIs/features in here, and I will put them on the website and gradually mark them off as they are completed. Also, if any ideas are mentioned in the post on the forums and I don't get to it first, then put them here.

[skwerlman]

We could have a debugging API designed to emulate as many features of the Lua 5.1 debug API as possible.

[dmarcuse]

I like that idea, but it'd be difficult.

I had also considered a better parallels API.

[skwerlman]

I already have some ideas on how to implement some of its functionality, so I think I'll at least start work on it.

[SuicidalSTDz]

Debugging API and Better Parallel API added to website suggestion list

Currently working on a better turtle API

[EngineerCoding]

Im inactive for the next 2 weeks due to school. Though Im here to comment ;)

[dmarcuse]

What do you guys think of an encryption algorithm?

[EngineerCoding]

Not really an use since anyone can look at this..

[dmarcuse]

One using a key, I mean...

[EngineerCoding]

Oh, really? Sorry, but isnt it obvious. Once the key isnt stored properly then they can get the string anyway. I think there is just no point.

[skwerlman]

It could still be used for computer-to-computer encryption with temporary, randomized keys. We could have a function in rednet like sendEnc( id, msg [, protocol (for 1.6)] ) that would first send a table to the recipient with the following format:

'::ENCKEY::'..publicKey

The recipient then replies the same way (we'd also have to alter rednet.receive), only encrypted using the public key. The sender then decrypts the recipient's public key, and uses it to encrypt their message before sending it. Upon receiving the message, the recipient decrypts it before returning the same data as rednet.receive (since that's the function we'll be using anyway). The reason we encrypt the recipient's public key is to try to prevent faked messages sent by computers who've intercepted the recipient's message. It wont prevent it, but it certainly makes it harder.

It's like a vastly simplified form of encryption via TCP. And, because the messages are encrypted dynamically, we avoid the issues of key theft and brute-force decryption.

[dmarcuse]

When I offered encryption as a possibility, what I had in mind was a way to encrypt files and data under a password the user would be responsible for storing. If the user saves the password in plaintext, then it's their fault the encryption is compromised.

[SuicidalSTDz]

Cleaned up old obsolete posts

[skwerlman]

Should the logger be built into the launcher and added to each APIs env, or should it be a separate API that the user can call?

[dmarcuse]

I think it should be built-in to the launcher. My process API would use it to log errors, for example, so we dont want it to error while trying to log an error because the user didnt load the logging API :P Maybe all logs are saved into the .enderapi folder as "log_0", "log_1", and so on.

[skwerlman]

Perhaps we could avoid that issue by loading it into each API's env table, and then loading it for the user as a separate API. If we could supply a path, we could have a log for APIs, and users would supply their own path when creating an instance of the logger.

[dmarcuse]

Alright, that could work.

[EngineerCoding]

My question is, why do we want users in our generated log? Doesn't make any sense to me

[skwerlman]

I just had the thought that they could define their own log locations, and we would have our own.

[dmarcuse]

Mm I'd rather supply a separate API for user logs. Which I could write if you want.

[skwerlman]

Sounds good to me.