Network API

[xoft]

Could be done, although I doubt the overall usefulness. For clients of a server that the plugin has created, the plugin can make such a list on its own (in the OnAccept() callback) and for a server created by a different plugin there's not much sense giving out those links to someone else - what, you gonna write to someone else's socket datastream??

[jan64]

As i said, it's not critical - but it'd be something nice to have.

[xoft]

It's looking good. I've integrated LibEvent into MCS and I'm starting to implement the internals. I just got cNetwork::Connect() working, more or less, the test code is now capable of downloading a web page over HTTP

[NiLSPACE]

Ooh that's awesome

[xoft]

I've pushed the initial code to GitHub, in the LibEvent branch. Go have a look, reviewers

I had to change the API a bit, based on obstacles that I came across. We'll see about the Lua API after the C++ part is finished.

[xoft]

As for the Lua API, I think I'll change the params around; instead of listing all the callback functions as separate parameters, I'll have the API functions take a single parameter, a table, that will contain all the callbacks in a map:

-- Callback-passing example:
local Callbacks =
{
  OnConnected = function (a_Link)
    ...
  end,
  OnDataReceived = function (a_Link, a_Data)
    ...
  end,
  OnLinkDisconnected = function (a_Link)
    ...
  end,
  ...
}
cNetwork:Connect("google.com", 80, Callbacks)

This is how the XML parser works, I think it's better than having a million parameters. Also it allows us to expand the API later on with new callbacks, when needed, without breaking existing plugins (much).

[NiLSPACE]

Yeah I agree. A table is better.

[jan64]

Sounds good.

[xoft]

I think I have finished one of the harder parts of all this. The API now has a server implementation that listens on both IPv4 and IPv6, where available; hopefully working even on older systems such as WinXP. The downside is that there is no longer a way to specify separate ports for IPv4 and IPv6. It might be possible to separate them again, but I'm not so sure about the usefulness of that; I think unifying the ports is a good side-effect. There will no longer be two settings for ports in the server config files (Port, PortsIPv6)

[NiLSPACE]

I have a virtual machine with Windows XP. I can test it if you want.