Wrapper to expose methods to initialise and connect to a server
Closed this issue · 11 comments
We need to access the methods in RakNet in order to use it in C#
Which changes to which classes would this require?
creation of an xcodeproj specific for compiling the RakNet into libs for iOS and XCode, and just a couple of extra files that would call RakNet code but have the extern "C" defined.
The goal is not to touch the existing files, just adding ways of reaching it from c#
That sounds OK 👍
creation of an xcodeproj specific for compiling the RakNet into libs for iOS and XCode
May this break existing ways of building RakNet within Xcode projects?
(Feel free to chime in, @alexandrepgfreitas)
The idea is to have a specific xcode project just for this and not touching anything else.
To be clear, we also tried the SWIG approach but the code being generated wasn't compiling, hence we moving towards this solution of creating the entry points ourselves.
There's some Xcode cruft in the repo already. Should we get rid of it?
We copied the xcodeproj from that and then removed the Test things, I'm okay with parting with that code as we have other ways of checking how to properly implement connecting and sustaining the connection with RakNet
@NStockwell: when you create the PR for this link it here, so this task gets closed at the same time as the merge.
I'm tentatively marking it as 4.4.0.
@g-andrade, we should probably give the project some ❤️ (e.g. README has an old version; there might be stuff that's outdated or out of place). What say you?
we should probably give the project some ❤️
I tried, earlier this week. Ended up too deep in the rabbit hole and backed out in horror. Most of the sub-components (dependent extensions, samples, the library source code itself) are inter-dependent in a complex web that's very difficult to untangle.
Therefore I discarded all my changes at the time, other than removing the version from README's title. Which isn't to say some minor polishes aren't warranted... but they bother me far less than all the unmaintained code which we don't need and will likely never use and is nevertheless a potential source of security issues.
In any case, something for me to reconsider, perhaps.
Additionally, here's a few of the things I thought, at the time, we should get rid of:
- Windows support (including Windows or Windows-phone -specific code, all the Visual Studio solutions and projects, references to building under Windows from README)
- Support for old consoles (PS3, XBox, etc.)
- All the CMake silverware
- Most extensions (as far as I can tell, we depend on
miniupnpc; we don't need any of the others) - Most samples (if not all)
- The humongous plethora of services that are part of the library source code which we don't need and whose existence introduces security risks
You should create an Issue for each one of those. In time, if all goes well, they'll be tackled.
Closing as I don't think this'll be done soon, and it's been a couple of months, already.
Do re-open if you need to.