srifqi wrote:Woah,
Hope it will be realized, can't wait to see 'em in server.
Here's what I've got so far:
https://github.com/technomancy/calandri ... t/init.luaNo broadcast/multicast yet. I have used it to facilitate communication between my terminal and server nodes. I haven't yet tried server-to-server or servers to other peripherals, but that's next.
If people are interested in using this in their own mods and games, I can spin it out into its own code repository.
I actually expected to implement this on top of digilines, but it turned out to be much easier to implement a "wireless" version that simply plucks nodes out of the air and delivers messages to them. I may consider a wired variant in the future or a gateway node that can route between the two network types. The advantage of the wireless approach is that communication happens much more quickly; propagation between digilines happens node-by-node, so far-apart blocks can take many seconds for messages to get delivered between them.
srifqi wrote:Will be there a browser? Just my thought.
Also, will be an URI-like (e.g. srifqi.server)? So, we don't have to remember the "IP".
The forms engine is far too primitive to support a browser unfortunately. Even emulating a 1980s "glass tty" is sketchy. I have thought about adding URIs but need to think more about what that would look like. I have a branch where I'm working on a DNS-like system though, because you're right: typing out the addresses is pretty tedious.
prestidigitator wrote:Why go part way? How about an implementation of HTTP/REST (GET, POST, PUT, DELETE) with Lua values (including table references) as the content type?
I actually feel like this is a superset of what HTTP provides. The main difference is that it is completely asynchronous rather than fitting into a neat request/response cycle, but such a mechanism could be built on top of the current API easily enough. You can think of methods also as being analogous to ports, where a single node can "listen" on a variety of methods by declaring callbacks. But packets are lua tables that can include lua tables (no need to flatten everything down into a single string or whatever) and you can easily include any fields you would normally put in HTTP headers. At that point it's more a matter of defining conventions than anything else.
Of course, a bridge between diginet and real-world HTTP feels like a no-brainer; unfortunately this is currently blocked on getting this pull request applied which was objected to for nonsense security reasons:
https://github.com/minetest/minetest/pull/1869