798 replies to this topic

[MKlegoman357]

dan200, on 04 November 2015 - 05:25 PM, said:

For CraftOS 2 i've added support for all the HTTP methods (post,get,head,delete,put), and sending and receiving a table of headers with each request (actually, i think the latest version of CC has this too). What else do you need?

In the latest CC version you can only send but not receive headers.

[Lignum]

dan200, on 04 November 2015 - 05:25 PM, said:

For CraftOS 2 i've added support for all the HTTP methods (post,get,head,delete,put), and sending and receiving a table of headers with each request (actually, i think the latest version of CC has this too). What else do you need?

Any chance we can get websockets?

[Lemmmy]

Lignum, on 04 November 2015 - 06:37 PM, said:

dan200, on 04 November 2015 - 05:25 PM, said:

For CraftOS 2 i've added support for all the HTTP methods (post,get,head,delete,put), and sending and receiving a table of headers with each request (actually, i think the latest version of CC has this too). What else do you need?

Any chance we can get websockets?

I second this. Websockets are insanely useful when you don't want to have HTTP headers flying around 20 times per second. A practical application for them would be a multiplayer game that works across servers - get a socket.io server running on node.js, then CC clients can freely connect. It would also be nice if SSL websockets were supported - the latest maven version of java-websocket does not support them but the latest jar on git does.

Edit: (also computercraft RTM slack client :3)

Edited by LemonLake, 04 November 2015 - 06:39 PM.

[oeed]

dan200, on 04 November 2015 - 05:25 PM, said:

For CraftOS 2 i've added support for all the HTTP methods (post,get,head,delete,put), and sending and receiving a table of headers with each request (actually, i think the latest version of CC has this too). What else do you need?

Receiving headers was basically the only other thing we needed really, that's how cookies are set and I presume OAuth works through sending and receiving the headers. I can't really think of anything else on the front.

That said, at some point sockets, as Lignum mentioned, would be great in terms of allowing better multiplayer games, which I can see being something people wanting to make even more so than currently.


One thing on receiving headers, in previous version if the response failed (i.e. wasn't 200) it just failed. Is there some mechanism (probably through http.request and the events) to catch the response even if it's 404 or the like? Essentially, do the .get functions wrap and handle the error code in Lua or is it canceled in Java/whatever environment it's running in?

Edited by oeed, 04 November 2015 - 10:01 PM.

[CraftedCart]

Added HTTP API overhaul to the G.Doc
Also, I've worked with OAuth before (outside of CC). I don't remember needing to use headers (But they are useful for OAuth). PostData what what I needed

[dan200]

Thanks for the info, I think my overhaul covers everything needed. CC already supports postdata though!

[ElvishJerricco]

dan200, on 05 November 2015 - 11:07 AM, said:

Thanks for the info, I think my overhaul covers everything needed. CC already supports postdata though!

I may have missed something, but I'm surprised no one has mentioned binary HTTP handles. Maybe this isn't irrelevant in CraftOS 2, but the issue with binary strings and undesired automatic unicode conversion makes getting binary data with HTTP literally impossible. It's been mentioned multiple times in the suggestions forum. Either binary HTTP or a fix to the string bug would be amazing.

[oeed]

ElvishJerricco, on 05 November 2015 - 11:52 AM, said:

dan200, on 05 November 2015 - 11:07 AM, said:

Thanks for the info, I think my overhaul covers everything needed. CC already supports postdata though!

I may have missed something, but I'm surprised no one has mentioned binary HTTP handles. Maybe this isn't irrelevant in CraftOS 2, but the issue with binary strings and undesired automatic unicode conversion makes getting binary data with HTTP literally impossible. It's been mentioned multiple times in the suggestions forum. Either binary HTTP or a fix to the string bug would be amazing.

I believe there was a bit of a hint a while ago in a Tweet about Lua strings being an array of bytes or something that maybe hinted that Dan was trying to fix/had fixed the string bug.

[MKlegoman357]

Based on the format of errors, CraftOS 2.0 is running the original Lua C implementation, which shouldn't have any string bugs.

Edited by MKlegoman357, 05 November 2015 - 02:18 PM.

[Creator]

Is LuaC faster than the one CC uses?

[Lignum]

Creator, on 05 November 2015 - 02:19 PM, said:

Is LuaC faster than the one CC uses?

Since C is generally faster than Java and since that's the original Lua implementation, which has been in development for over 20 years, yes, that's probably the case. However, that also depends on what the new project is written in... native calls from within Java aren't exactly fast, mostly because the arguments need to be converted from Java to C. However, if done properly (take LWJGL as an example), you'll end up with little to no overhead.

[FUNCTION MAN!]

Lua is, generally, slow as f***. The virtual machine doesn't do inlining or JITting because that's not cross platform enough. LuaJIT, however, is fast as all hell, even faster than C in some cases.

[Creator]

How is LuaC related to LuaJIT?

[CraftedCart]

dan200, on 05 November 2015 - 11:07 AM, said:

Thanks for the info, I think my overhaul covers everything needed. CC already supports postdata though!

I thought it did... It was too fiddly to search up the wiki on my phone though (my lame excuse for, I couldn't be bothered to check)...

[ardera]

dan200, on 04 November 2015 - 05:25 PM, said:

For CraftOS 2 i've added support for all the HTTP methods (post,get,head,delete,put), and sending and receiving a table of headers with each request (actually, i think the latest version of CC has this too). What else do you need?

If you didn't already implement this (but I think you did), HTTP response codes and the possibility to read headers and the response body even on failure.
Raw TCP would be cool too

Edited by ardera, 06 November 2015 - 12:49 PM.

[Creator]

The seven network layers would be cool.

Or is it called protocols?

[oeed]

Creator, on 06 November 2015 - 12:56 PM, said:

The seven network layers would be cool.

Or is it called protocols?

Methods

[ElvishJerricco]

Creator, on 05 November 2015 - 04:08 PM, said:

How is LuaC related to LuaJIT?

It's sort of not. LuaJIT is its own separate project. It's just also written in C (and this DynASM thing the guy made to go along with C).

[SquidDev]

ElvishJerricco, on 06 November 2015 - 05:33 PM, said:

Creator, on 05 November 2015 - 04:08 PM, said:

How is LuaC related to LuaJIT?

It's sort of not. LuaJIT is its own separate project. It's just also written in C (and this DynASM thing the guy made to go along with C).

It also can reach the speed of C (that is the language rather than "c" - the speed of light) for some tasks (though most of them are heavily maths based). The interpreter is hand-written in assembly to achieve maximum speed. It is an incredible project. Drools.

[oeed]

I've been doing experiments with putting photos in Silica, I won't be posting screenshots of it or the OS anymore until release just to keep the surprise level high, but I'll say they're better that you'd think.

However, there is one small (maybe small isn't the right word here) issue. If the files are use the paintutils image format they're not exactly light weight... at all. One 320 x 200 (the size of the screen) image was 64kB (as you'd actually expect when you think about it). Given that the OS already uses about 700kB without any images, this isn't exactly great.

I'd propose a bit of discussion about a suitable image format; ideally it'd also include the palette data. I was thinking squishing two pixels in to one (one pixel uses 4 bits, half a byte) but even then a single image would be 32kB. Compression would naturally be the next stage, but I know very little about that.

This might not turn out to be a massive issue, hopefully Dan will increase the storage limit to at least 10 - 20MB, and if that's the case then a couple of 64kB image won't be a huge issue, as it would've been in regular CC.

Edited by oeed, 07 November 2015 - 02:05 AM.