OK then. Let's stop arguing about this as an abstract problem and do this right:

What should such a server implement? So far my client needs discovery of installed games.

What protocol should it use? Personally, I love named pipes, because thery'e small and quick to write... or would we need a full blown HTTP server?

What should they use as a format? SOAP may have been all the rage, but I find it big and cumbersome. A nice little JSON or XML-based format?


EDIT: If you want to use the code in the repo, I just updated the README:

In order to get this to run you need a recent XULRunner version from
[url=ftp://ftp.mozilla.org/pub/xulrunner/nightly/latest-mozilla-central]ftp://ftp.mozilla.org/pub/xulrunner/nightly/latest-mozilla-central[/url]/

Put the XULRunner directory (not its content) from that archive into your
repository. Don't worry, it will not be synced. Take the xulrunner-stub.exe
and copy it into your repository directory. Rename it to GamesDesktop.exe
to keep it from getting synced.

For now, the code is Windows-only, although there are discussions about
a cross-platform toolbox.

Definitely JSON and if possible an embedded webserver.

Or MessagePack :D http://msgpack.org/

I think that's actually slower when used on a local loop connection and decoded in Javascript :)

I do not know, but the performance statistics from some comparisons with other libraries shows very good results for the C and Java version of MessagePack

https://github.com/msgpack/msgpack-javascript

Maybe there is also a newer fork or someone compiles it to JavaScript eg using Emscripten ... but this is just an idea ;-)

But keep in mind: don't use any library by Douglas Crockford (regarding his "awesome" license") ...

Won't work. I've actually manually written some asm.js code, and even in the best of cases the performance gains aren't nearly as big as you would expect, Code that's straight-forward enough to compile well through ASM.js works equally through tracing. You usually get an additional 15% or so. C is still a good deal faster and JSON is implemented in C. But the real issue is that we don't need the performance in this case. And even if we did, the best way would be to avoid the HTTP protocol, not JSON.

So, how should the process be. Keep in mind that there may be lengthy requests and sometimes bi-directional ones. Something the HTTP-protocol is very much ill-equipped for.

Let's assume that downloading a game and installing a game are part of the commandset. These are pretty much the worst cases, that's why I want to start with those:

Calls needed:

DiscoverAvailablePacks: to see which items can be downloaded. It will return AUTH_NECESSARY because that information is not available for a user who isn't logged in.
UserLogin: to log him in with user-supplied information
DiscoverAvailablePacks: again. This time it will hopefully succeed, if not: repeat. Will return a list containing game pack ids
PackGetVersion: to see what version is offered
GetInstalledPackStatus: to find out whether it is installed and if yes, which version
Download: will fail with STATE_NOTARGET, because no default download path was specified
SetDownloadPath: to set the default Download path
Download: now returns a UInt64 downloadId or DOWNLOAD_EXIST (which requires calling Download again with an overwrite flag)
DownloadGetStatus: (queried every 5 seconds or so) returns either DOWNLOAD_ERR_INSUFFICIENTSTORAGE, DOWNLOAD_ERR_UNKNOWN, DOWNLOAD_ERR_NETWORK, DOWNLOAD_PROGRESS (along with data about the progress) or DOWNLOAD_COMPLETE (along with the paths of all downloaded files).
SilentInstall: Fails with INSTALL_NODIRECTORY. Let the user chose a default directory or alternatively launch a non-silent install.
SilentInstallSetDirectory: To set a parent folder for all silent installations. Returns a UInt64 InstallId
InstallGetStatus: (queried every 5 seconds or so) to provide progress updates if available. INSTALL_ERR_* on errors, INSTALL_COMPLETE along with the new game pack Ids

Does that sound about right?

Sounds good so far.
What about extras, languages, updates, continue canceled downloads ... I mean, do we have to adapt the methods used in the (l)gogdownloader version(s)?
I think you can also choose even more options for the InnoInstaler which GOG uses like language, desktop icon.
How far is this scriptable from the outside? We can unpack Inno Installers for example ...

Or is this not initially needed?

Not for me.... I only want to deal with installed items for now... it's really just about how to deal with lengthy requests. Extracting innosetups is cumbersome and errorprone. Don't do it. We can use what the installer offers, but no more.

I only want to nail the structure of the requests to GOGToolbox, so that we don't have to break it later when we implement downloading and installing. How to deal with options and so on is something we can discuss when we actually implement the functionality.

I was really only concerned about whether simulating bi-directional communication this way would be OK.

I fear that the best I can do is a random bump of this thread, now and then...

Bump?

What is a bump?

----

Bump.

I did read the post, which is why I specified arbitrary contributors. There's use building an army then being permissive. You might as well be permissive from the get go and just open yourself up to the world's volunteers.

Hi, I'm just bump8ing this to say that a little while ago I made a script (which I called "GetGOG") which detects games on PC and matches them with my GOG library. More recently I began building a UI for it but I've not really had the time to work on it much. Maybe I'll release it some day but it might be better for me to contribute to another project.

As I said I've not got a lot of time at the moment and I don't really know XUL (it's just javascript right?) but if there was some easy way to contribute code or give general advice then I'd be interested.

Btw, have you spoken to the person that makes the Linux client thing? I've not looked at it myself but it seems like it could be helpful.

Any new on this?