I made some specifications, but they aren't related to those I brought up earlier in the thread. So I'll rename the thread to be more generic. I'll keep posting some specifications here for discussion as they come up and I think they are polished enough. This one I think is pretty simple and could make quite some difference.
Custom protocol handler:The name is pretty generic, and it might not be what it sounds like so read the description
Have you ever used Spotify? Say you could make links like theirs work for OLX. Clicking the URL launches spotify with some specific arguments. If spotify is already open, the action will be performed in the active instance of spotify. Spotify specifies a custom protocol handler for the "spotify" protocol. So you can create URIs specific content in their context. Say we create a similar custom protocol "openlierox". There could be two types of links; "game invite" and "content download".You would click the link and OLX would perform the action. The links could then easily be spread through IM, forums and ingame. They would look something like this:
openlierox:game\$ip[:$port]
openlierox:download\$type\$id
Clicking on a game invite link will cause the OLX client to attempt to join the game described by the link. If the client is open, the game will use the opened instance (single game instance). Otherwise, a specific OLX (one specified in the protocol handler) will be launched and will attempt to join the server.In both cases the user will be asked if he wants to join the server and will be allowed to choose which character to join with.
Download links will download the specified file from the filebase and use the game's content downloading function to download and install it properly for the active OLX. Again, the user will be prompted if he wants to download the file (possibly along with a preview of the level or skin). This could have an application in a future built-in filebase etc.
Requirements:
Custom protocol handler: In order to handle the custom "openlierox" protocol, the environment must be configured to handle them accordingly. This is different between systems, so several special cases might have to be considered (Windows, OSX, Gnome, KDE...). The protocol handler must be "installed" - that is the system must be told what to run when encountering a URI with a specific protocol. This can be done when OLX is started. When a new instance is successfully created, it will check if the protocol handling needs to be modified.
The protocol handler will be launched when the URI is invoked. It points out an instance of OLX that will be appempted to be launched. This means that extra care must be taken for the protocol handler to attempt to launch the correct OLX "installation".
Single application instance: If the link is supposed to perform the action in an already active application, we would need to limit the amount of open OLX instances to one. I think a practical way of acheiving this is to attempt to bind a specific port to OLX at startup. If the port is already bound, we check if the port is bound by and OLX instance. If not, try another port. If the port is indeed taken by OLX, send a message through the socket with the action to the active instance.
Message sending to OLX application: There needs to be a way for an OLX instance to receive an handle messages from the outside. Possibly restricted to messages from localhost.
Instant game joining: This might be the hardest thing to implement about this request. The client needs to be able to join a new game from any state. Both from an uninstantiated state and ingame. If the game is not instantiated, it will first load everything necessary and then prompt to join the game. The changes here suggest that OLX would use a pre-launch phase where it checks if there is already an instance of OLX loaded. If there is one, a message will be sent there containing the actions to take and then dies. Otherwise, the pre-launcher will make sure the protocol handler loads the correct pre-launcher. The application would thereafter be launched normally.
Note: If a port occupied by a non-lx application at the time of the first check and freed at the time of the second, it would be possible for several instances of OLX to coexist. There is probably a better solution to this. Like process-bound files or Mutex solutions...
[Army of Glory] - [AoG] ([AoG])
by Morby
