It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
Community
General discussion (archive)GamesDesktop : A launcher for GOG - Pre-Alpha - Help needed(46 posts)(46 posts)
(46 posts)
Pages:
1
2
3
4
This is my favourite topic
Posted February 10, 2014
avatar
HiPhish: I don't think it's pointless, such a "GOGTools" library could be used by various projects. We already have an unofficial Linux downloader, a Java port of said downloader and now a Windows client. I just think it would make sense to sit down and write this one part once rather than having everyone re-invent the wheel. Oh sure, you can look at someone else's code and adapt it to your needs, usually that's not that hard, the problem is that each of those implementations has to be maintained individually instead of just updating it once and everyone profits.

Yeah, it won't matter in this case, not in the next or the one after that, but in the big picture it's re-inventing the wheel each time.
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.
Post edited February 10, 2014 by hansschmucker
Posted February 10, 2014
avatar
HiPhish: I don't think it's pointless, such a "GOGTools" library could be used by various projects. We already have an unofficial Linux downloader, a Java port of said downloader and now a Windows client. I just think it would make sense to sit down and write this one part once rather than having everyone re-invent the wheel. Oh sure, you can look at someone else's code and adapt it to your needs, usually that's not that hard, the problem is that each of those implementations has to be maintained individually instead of just updating it once and everyone profits.

Yeah, it won't matter in this case, not in the next or the one after that, but in the big picture it's re-inventing the wheel each time.
avatar
hansschmucker: 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.
Post edited February 10, 2014 by Daniel Ruf
Posted February 10, 2014
avatar
Daniel Ruf: Definitely JSON and if possible an embbeded webserver.
Do you mean for your webserver where the client gets some data? Is this allowed by the GOG team or do we have to access the GOG API directly? Just to be sure that we have no legal problems.

There are some great "API-centric PHP frameworks" (on Github)
My web server stays completely out of it. We're talking about

GOG.com <-- DOM/GOG.api -->GOG Toolbox
Windows Registry <-WinAPI-> GOG Toolbox
GOG Toolbox <--pipes or http + json --> client


When I'm talking about server in the context of an application, I usually mean what others describe as MODEL. Sorry for the confusion :)
Post edited February 10, 2014 by hansschmucker
Posted February 10, 2014
avatar
Daniel Ruf: Definitely JSON and if possible an embbeded webserver.
Do you mean for your webserver where the client gets some data? Is this allowed by the GOG team or do we have to access the GOG API directly? Just to be sure that we have no legal problems.

There are some great "API-centric PHP frameworks" (on Github)
avatar
hansschmucker: My web server stays completely out of it. We're talking about

GOG.com <-- DOM/GOG.api -->GOG Toolbox
Windows Registry <-WinAPI-> GOG Toolbox
GOG Toolbox <--pipes or http + json --> client

When I'm talking about server in the context of an application, I usually mean what others describe as MODEL. Sorry for the confusion :)
Or MessagePack :D http://msgpack.org/
Posted February 10, 2014
avatar
hansschmucker: My web server stays completely out of it. We're talking about

GOG.com <-- DOM/GOG.api -->GOG Toolbox
Windows Registry <-WinAPI-> GOG Toolbox
GOG Toolbox <--pipes or http + json --> client

When I'm talking about server in the context of an application, I usually mean what others describe as MODEL. Sorry for the confusion :)
avatar
Daniel Ruf: Or MessagePack :D http://msgpack.org/
I think that's actually slower when used on a local loop connection and decoded in Javascript :)
Posted February 10, 2014
avatar
Daniel Ruf: Or MessagePack :D http://msgpack.org/
avatar
hansschmucker: 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") ...
Posted February 10, 2014
avatar
hansschmucker: I think that's actually slower when used on a local loop connection and decoded in Javascript :)
avatar
Daniel Ruf: 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.
Posted February 10, 2014
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?
Post edited February 10, 2014 by hansschmucker
Posted February 10, 2014
avatar
hansschmucker: 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
GetInstallStatus: 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?
Post edited February 10, 2014 by Daniel Ruf
Posted February 10, 2014
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.
Post edited February 10, 2014 by hansschmucker
Posted February 10, 2014
avatar
amok: My programming skills is limited to being able to make a button appear in VB, so I can not help, but I would be interested in the result.
avatar
hansschmucker: That's fine. If we get this thing off the ground, we'll need everything from experienced programmers to UI-people to people maintaining a database to people writing documentation. So don't think you're going to get off easy just because you don't know JS ;)
I fear that the best I can do is a random bump of this thread, now and then...
Posted February 11, 2014
avatar
hansschmucker: That's fine. If we get this thing off the ground, we'll need everything from experienced programmers to UI-people to people maintaining a database to people writing documentation. So don't think you're going to get off easy just because you don't know JS ;)
avatar
amok: I fear that the best I can do is a random bump of this thread, now and then...
Bump?

What is a bump?

----

Bump.
Posted February 11, 2014
avatar
hansschmucker: You didn't read the post :) . It's just until I know that anybody is interested in joining. Nobody can do collaborative work under such a license and nobody should have to. It's really just that: A temporary license until I know what to do.
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.
Posted February 18, 2014
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.
Post edited February 18, 2014 by ChrisSD
Posted March 16, 2014
Any new on this?
Pages:
1
2
3
4
This is my favourite topic
Community
General discussion (archive)GamesDesktop : A launcher for GOG - Pre-Alpha - Help needed(46 posts)(46 posts)
(46 posts)