Network API
#31
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??
Reply
Thanks given by:
#32
As i said, it's not critical - but it'd be something nice to have.Tongue
Reply
Thanks given by:
#33
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 Smile
Reply
Thanks given by:
#34
Ooh that's awesomeBig Grin
Reply
Thanks given by:
#35
I've pushed the initial code to GitHub, in the LibEvent branch. Go have a look, reviewers Smile

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.
Reply
Thanks given by:
#36
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).
Reply
Thanks given by:
#37
Yeah I agree. A table is better.
Reply
Thanks given by:
#38
Sounds good.
Reply
Thanks given by:
#39
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)
Reply
Thanks given by:
#40
I have a virtual machine with Windows XP. I can test it if you want.
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)