Fair enough and thanks for the heads up! Please let us know when the protocol will stabilize. Alternatively though, if you are interested in community participation you can publish at least a high level description of the current protocol, which will allow commenting with ideas and improvements before you finish the spec. Just a thought.

Yeah. Even among those of us who haven't actually written something along those lines before, there are programmers like myself whose favourite form of procrastination is reading retrospective blog posts and implementors notes by people who have.

When developing any software that implements a public API, a network communication protocol, or similar publicly digestible interfaces a lot of things can change as it is in heavy development much in the same way that programming libraries can change heavily in development. Once a developer publishes an actual protocol specification or library API for something that is experimental and subject to change - people who want to use it end up using it and then they end up relying on it and expecting that it wont change at all. People get angry when APIs, ABI's, protocols change suddenly and unexpectedly even if they are considered ephemeral all along by the developer. If something is likely to randomly change in incompatible ways regularly until all of the features in something are implemented and the chosen approach decided upon, it is generally not the best idea to pre-publish the specifications of things in advance, especially if it is something that will end up being a protocol/API etc. that is relied upon by 3rd party software where people will invariably get upset if it changes.

As a developer myself I am eager to eventually get to poke at the Galaxy APIs myself but I doubt that we're likely to see any official documentation about it for some time because in the heat of development that Galaxy is in right now things change frequently and having to make usable documentation for something that changes frequently and randomly is a lot of extra work and ultimately wasted effort. While Destro gave a good high level answer above, I'll speculate that they have a specific set of features they plan on implementing and general ideas on what they want to do and they'll be putting that together and changing it frequently and flexibly because it's just a normal part of development. Once they finalize on a particular protocol/API and set it in stone, then they are likely to consider writing official documentation for it and make it publicly available but I doubt they'll do that until they're sure they have an API/protocol they're quite happy with and feel confident they wont need to change in an incompatible way. That's ultimately just good development. :)

The worst scenario to be in is to pre-publish information to people way before things are remotely feature complete and stable, have 3rd parties write software to your incomplete and ever changing spec, then break it every day and have them upset and trying to chase an ever changing thing in which the documentation is never completely up to date to the latest changes.

I suspect we wont see any documentation until sometime weeks/months after Galaxy final is officially released and out of beta, but I also think that is the best approach as a developer to take as well both for the people writing the code, and for 3rd party developers. What is however pretty awesome is that GOG has actually committed to providing such information at some point in time when they feel things are stable and they're ready to do so.

Many folks (myself included) are all eager to see this, but ultimately we need to be patient and trust them do complete their goals and finish their work and then iron out public documentation to come later when it's ready. Or as I like to put it myself... When It's Ready(TM) ;oP (Thank you John Carmack for that one.) ;)

No, that's not reasonable. Why would anyone rely on anything experimental without expecting it to change? It's just silly. That's why when IETF publishers some draft of the protocol specification, it's clearly marked as a draft so all participating parties would not rely on it as anything final. However publishing work in progress helps improving things and getting feedback from all interested parties. That's how IETF works (and that's how all important Internet protocols are developed by the way, consider HTTP for example).

It is human nature to do so (rely on something). I'm a developer, I've been doing this for 20+ years, I know this is how it works because I've done this very thing before many times and experienced these very things first hand both with library APIs and communication protocols. It's reasonable because this is GOG's proprietary API, not an open public standard to be published by the IETF. If they chose to design Galaxy as an open source platform, or to design the protocols it communicates with as an open public standard and in conjunction with other parties then the design would be either discussed in public or private forums with the various parties whom are all involved in the design. But that's not what they're doing, and they never claimed they were doing that. They said that they would publish documentation eventually so that 3rd party clients could interact with the service </paraphrase>

I know how the IETF works and how other public standards processes work as well, I've been around that stuff for more than half of my life. This is not an IETF standard, it is proprietary software to which will have a public API that is documented for use by 3rd parties at some point in time unless of course I am mistaken and GOG plans on it being open source or submitting it to the IETF as a draft in which case I will have made incorrect assumptions and will stand corrected once they make that information known to us.

Quick, someone jump in and tell me how it is DRM now! :)

Since GOG want to publish the protocol specification, it's comparable with any other open protocol, so why can't it be developed in a similar fashion to how other protocols are developed? No special reason except may be GOG not being interested in feedback (or not being able to handle it because of limited resources and etc).

Nothing really makes a protocol "proprietary" besides obscuring its details. And GOG don't intend to obscure them.

Firstly, whether the client is open or not has nothing to do with whether the protocol should be open or not. There are many closed e-mail clients which perfectly use open and publicly documented e-mail protocols and so on. Let's separate interfaces from software that uses them. Secondly, GOG can as well open source their client too, but it's a separate subject.

I'm not sure why you conflate unrelated subjects (openness of the client, openness of the protocol and DRM). Closed protocols usually contribute to the problem of lock-in, not to the problem of DRM. So, please focus on the matter at hand which is Galaxy protocol.

I'm an open source developer and community member myself and strongly in favour of open source software, and free open public protocols. As such I'm totally in favour of GOG developing Galaxy client as an open source application or open sourcing it at a later date, and I'd also be in favour of the protocols they use being open as well.

While I am in favour of that though, I do not feel that they must or even should do that nor do I have any sense of entitlement for such either (Edited: Note that in saying that, I am not implying that anyone else in particular does but there probably are people who do.) While I greatly prefer things more open than not I respect an individual developer or company's choice to develop their software in their own manner whether it is open or closed and I make no demands about it.

If we were to sit down face to face at a table over a cup of coffee to discuss this you'd find that we probably have a lot more common in thinking about such things than not, although we'll likely differ in some areas as well and that's ok too.

For the record I don't really disagree with anything you've said in your last comment above, I just don't think GOG is obligated in any way to develop their software in that manner unless they wish to do so for their own reasons and if they choose to do it in a closed development model as proprietary software and protocols, I don't see a problem with that personally even though I too would prefer to see open protocols and open source as is my general nature.

Either way I believe they're going to provide us with a nice piece of software and eventually at some point an SDK and other tools with which to interact with their services and whether it is open or not I think it is going to be a huge step forward than anything we've had before and I'm looking forward to that even if it isn't open or developed in the public eye.

Others will likely feel very differently about this for their own reasons and I can totally respect that too as I don't think there is a right or a wrong personally just different approaches and individuals have their own thoughts about these things. Nothing wrong with people sharing different viewpoints here to let GOG know their thoughts/preferences either. Ultimately they'll decide what to do and we'll end up with something one way or another. I look forward to it whatever it is, however they do it.

I apologize for the DRM comment, that was purely intended as light hearted humour and nothing more, but perhaps was out of place in the wider scope of the discussion. I have a fondness for injecting humour into things and it isn't always obvious or seen that way by others sometimes.

At any rate, under the surface I think we likely agree on more things than not to be honest.

any news on this?
Just wrote a shortcut creation script for steam : https://gist.github.com/blunet/f0e14a3d38ed1c3ba36b
Now i'd like to do the same for my GoG Galaxy games. But how?
So far the easiest way seems to find all the shortcuts Galaxy forced into the start menu (rudely "scan and import folders" creates "GameName [GoG.com]" folders in the startmenu root folder) & move/copy them. (even more evil: if the shortcuts were moved/renamed, "repair" recreates them!)

Related question: How can i force Galaxy to put its shortcuts into "StartMenuRoot\GoG\" ?

I can think of at least 2 ways:

1) By binary hacking the executable in a debugger, however that would likely be an extreme endeavour.
2) Apply for a job at GOG as a developer working on Galaxy - https://www.gog.com/work

But before rushing to either of these solutions I would suggest that a simpler way to do it would be outside of Galaxy by writing a simple application that can scan looking for shortcut files recursively through the directories where you install your games via Galaxy, and copying them into another subdirectory of your choosing. It'd be easy to do in a batch file or similar however my batch file mojo vanished around 1998 or so.

In Linux parlance you could do that with something along the lines of:

find "C:\Gog Games" -name "*.lnk" -exec cp {} "C:\<pathtoStartMenuFolder>\GoG\" \;

I'm sure some DOShead/WindowsHead can turn that into something Microsoftish if need be. It could be automated to run once an our/day/week/whatever to keep the shortcuts up to date to some degree of granularity. If someone were ultra-geeky enough and wanted to be fancy-pants about it they could write a background daemon to monitor the directory heirarchy for file change notifications of new files with .lnk extensions appearing and trigger a copy right away.

Sure beats binary editing an executable. :oP

Thanks! That would be a bit of an overkill and i really don't want to debug disassemblies... moving to warsaw? no thanks, way too cold up there :-)

yeah mine too, but i acquired a lot of bash mojo since then... and i've been hearing about that powershell thingy... so i went ahead and dove in. Turns out i really don't like powershell... but hey i achieved the goal : Gog shortcut cleanup script.

That i leave to someone with proper .net/win32 skills... i was just not going to manually copy almost 300 links from as many folders into one... that i leave to the apes or robots :-)

Almost anything does :-)

That's the spirit! :)

Windows has a task scheduler built in, however to be honest I've never actually tried to use it. Probably simple to figure out in a few minutes though. Depending on how big a thrashing your script gives the disk you could schedule it once a day or whatnot. :)

I'm somewhat surprised GOG / CDPR don't have more remote work. Almost all of their positions are local.