Alexandre Julliard wrote:
Jacek Caban jacek@codeweavers.com writes:
Yes, that's my plan, but I'm not sure why it's important for this patch. Currently Wine downloads always the same Gecko version that was never updated, so this check should work with current Wine. It will change once we will switch to the new version. I have patches that will use query encoded in URL to specify the package version and it will use the same defined version string as version check in this patch, so switching to the new Gecko won't be much more than one line patch.. It requires changes both in Wine and redirecting php script. I have patches for both and this was the first patch in this direction. I only have to test the rest of patches and send them (hopefully I will find the time to do it tonight).
My concern is that this sort of thing needs to be planned correctly to work in the long run, and it's not clear what the purpose of that version check is. Is there a dependency that would make Wine require a specific version? What happens if you use a new Gecko with an old Wine? Can you make different versions coexist?
The plan is to pass the version in URL query. Then the redirecting script will take care on choosing the correct file from SourceForge. It's backward compatible as older Wine won't pass the version so script will assume that an old Gecko is requested. The new Gecko doesn't work with old Wine (that's why we have to guaranty that it will download an old Gecko). It's because we depend on some Gecko behaviors that have changed. It's both due to Wine (we have to do some not nice tricks, to not say ugly hacks, to make loading document work correctly) and not perfect backward compatibility of Gecko. Also it's not guarantied that newer Wine will work with older Gecko. Currently it will work, that's why I think simple message is enough for now to not force people to download over 5MB if their apps work without it. But we have to use some unfrozen interfaces and they may change in the future preventing backward compatibility. Although we probably could add some workarounds when it will happen, I would be painful to support few Gecko version. So if it will happen in the future, then we can change this check to never use older Gecko (and perhaps add a nice updater). By coexisting different versions you mean in one Wine prefix? Yes, it would be possible, but I don't see much point of it. If you think it should be done this way, I may implement so (it prevents current patches, these changes would be in another peace of code).
We are very far from being able to support other archs, so I thought it's not worth to care about it ATM.
But then there's no sense in adding #ifdefs for it. Putting the architecture in the request wouldn't be much harder, and would avoid hardcoding in the client knowledge about what files are available on the server.
I've sent patches that replace previous ones. There are removed #ifdefs. We may back to arch problem later, just like we do now with different versions.
Thanks, Jacek