Well sockets ever be a reality?

I have heard that sockets was once in Codea but got taken out, if this is true then why?
And will they ever return?


It was against apple agreement or something along those lines, just didn’t pass the checks when being released and since then it hasnt been included, they have been planning to try and add it again, at least that’s what I understand to be the case

@Luatee no it’s not against policy. We just wanted the easier http.request API instead. I can put sockets back, I’m not very fond of the polling style API though — feels very un-Lua

It would be awesome adding it back for faster connections between server-client so for example i could write a server and run it on my computer, then clients could join the server and play the game, live.

Or maybe for the use of doing IRC things. I had in mind creating an IRC bot that was easily expandable.

@Simeon ahh right, thought I saw you say something different, in that case sockets is a good shout

@Simeon Sockets would be awesome as unpleasant as they are. They’re very powerful :slight_smile: Which implementation flavor would it hypothetically be Berkeley (BSD) or POSIX ?

I was a GIANT pusher for sockets - and I had a chance in the beta to mess with them. So - I can speak from experience a bit on how they’d work in Codea, and the answer was - not very well, frankly.

The real issue is that regular old sockets, and the lua sockets library, are written using the good old block-and-read paradigm; while Codea is very centered around a draw loop. This caused what I describe as an impedance mismatch - you need to jump thru some pretty ugly hoops to try to marry those models, and in the end I was quite unsuccessful (you might be able to do something with coroutines, but I was never able to get my head around it enough to demonstrate working code).

The TLL guys had the right solution - register a callback, so you don’t have to block waiting. It’s not as clean as blocking code, but you aren’t blocking, so you can keep your draw loop going, and it’s very workable. They did the http call, and that fills perhaps 90% of the need for many projects.

If we were ever to revisit doing sockets, in hindsight the best solution for Codea would probably to do the same thing they did for http - make a call to register a callback. So, rather than fork and accept on the socket, you tell Codea to listen, and call you back on connect (and on data being available) - and let it deal with the forking and other shenanigans behind the scenes. Problem is - that’s a non-trivial amount of work, and when I was calling for sockets, the TLL crew was busy doing insanely cool things like meshes and such, which frankly provide a lot of bang for the buck, so I’m very hesitant to second-guess what they’re working on. :slight_smile:

I would, having said that, find a lot of use for UDP sockets; they’d be conceptually dead simple to use, and I can already think of 47 things I’d do with em.

udp sockets please :slight_smile:
Really need it so I can drop my server and listen for packets directly.
@Simeon. Got the impression earlier that it was hard to make this happen, but from your own words above that seems to be the opposite… so please do not hesitate :slight_smile:
Re Peter

It would be very hard for us - Codea Users - to use the stock lua UDP (indeed, socket) code, because it’s blocking.

But TLL can wrap it with a callback mechanism - like they did in http.request - and it would be quite usable; and I hope not super difficult, as they’ve already done a lot of the work for http.request. The two major reasons I’m not going on and on about it are (1) it would be new code for them to write, and (2) I trust their judgement about what people want and/or what they want to add. Aircode is pretty cool. I suspect/hope they’ll get bored or run out of ideas and add it at some point. :slight_smile:

Theres a module for Garry’s Mod that deals with mysql, it for example has a function for blocking until the query was done, maybe a similar thing could be done with sockets, so you have the oppertunity to use either blocking sockets or callback sockets.

@Simeon I would like to know if anything is being done with this request :slight_smile: