Main Area and Open Discussion > General Software Discussion
What the hell is OpenCandy?
wraith808:
A little update- I was installing Applian FLV player on my new computer. It uses Open Candy. Or at least I *think* it does. Looking in the EULA, it has something about OpenCandy. But I wasn't presented with any option other than installing their own premium version... so I'm not sure *what* that was about...
-wraith808 (April 05, 2011, 01:14 AM)
--- End quote ---
Do you have the Freecorder toolbar?
-PhilB66 (April 05, 2011, 02:12 AM)
--- End quote ---
I don't even know what that is. I don't have any toolbars in my browsers, though. And nothing was installed other than the FLV player.
40hz:
I'm going to go back to your definition of installation (you knew that was going to happen... didn't you? ;)). At the time that this dialog would be accessed, the open candy dll would already be in memory. There's no way around it. The installers don't dynamically link the DLLs so that they only load them on demand. They decompress the payload, put it in a temp directory, and run with the bootstrapper linked to the resources in that directory.
-wraith808 (April 05, 2011, 01:09 AM)
--- End quote ---
Yeah. This is where OC's real 'innovation' lies IMO.
And from my perspective, that's what makes it unacceptable.
I'd be happier if OC provided the partner developers with a full installer that the devs could load their application into rather than the other way around.
But I doubt that will ever happen for a variety of technical, legal, and business reasons.
As a result, I'm probably never going to be able to agree with OC that theirs is a proper and acceptable way to do things. Fortunately for them, it's not my opinion that controls the marketplace.
So no problem. It's their decision and their product. They can do things however they think best. And if people are willing to go along with it...well...so be it.
:)
40hz:
Trying to come up with a compromise that would suit both perspectives... Not sure if that would work.
Try to think "in principle" and not about OC. OC is just one example. There are others as well.
-Renegade (April 05, 2011, 04:38 AM)
--- End quote ---
I think in light of what wraith808 was saying about how the DLL works in conjunction with the installer, it's kinda moot at this point. OC is active the minute the installer loads into RAM. No getting around it.
Probably the best you can do by way of compromise is go with your second idea where the installer splash screen directs the user to review the EULA for details about what OC is and what it's there for. (see below)
Beyond that, there's not much else you (as a developer-partner) can do with the way OC currently is set up to work. Or at least nothing short of deciding not to use OC at all.
Besides, if people can't be bothered to at least look at the EULA, there's little to be done for them. Much as it galls me to say it, that's the sad truth of the matter. And life is way too short to get super hung-up trying to help people who don't really care about what you're trying to help them with. It's just "horses to water" at that point..
Onward! :Thmbsup:
--------
P.S. Nice splash screen design BTW. Really like that camera graphic. :Thmbsup:
f0dder:
Umm, how does OpenCandy work, again?
Do they provide their own entire installation framework, or is it "merely" a plugin DLL available for use with 3rd party installers like NSIS, InnoSetup, InstallShield et cetera?
If it's a plugin, then Wraith isn't entirely correct - the DLL won't be part of the installer.exe import table, and it will be loaded dynamically. Now, it's several years since I've played with installers, so it could very well be that the major installers load all contained 3rd party DLLs as soon as possible... but that sounds a bit stupid.
wraith808:
I'm going to go back to your definition of installation (you knew that was going to happen... didn't you? ;)). At the time that this dialog would be accessed, the open candy dll would already be in memory. There's no way around it. The installers don't dynamically link the DLLs so that they only load them on demand. They decompress the payload, put it in a temp directory, and run with the bootstrapper linked to the resources in that directory.
-wraith808 (April 05, 2011, 01:09 AM)
--- End quote ---
Yeah. This is where OC's real 'innovation' lies IMO.
And from my perspective, that's what makes it unacceptable.
I'd be happier if OC provided the partner developers with a full installer that the devs could load their application into rather than the other way around.
But I doubt that will ever happen for a variety of technical, legal, and business reasons.
-40hz (April 05, 2011, 02:18 PM)
--- End quote ---
I don't think that will happen (very much technical reasons here), but there is a possible compromise (though it might just be splitting hairs). Have a bootstrap dll that is loaded into the installer space. After the user OKs the use of OC, that bootstrap dll then loads the OC dll dynamically. Of course (1) that bootstrap DLL would still be OC code, and (2) that's a lot of effort for very little gain (see splitting hairs).
* wraith808 shrugs
As I said above, there's a lot of little details that I think will never make this anything other than a huge divide between certain parties. There's no way to satisfy the nay sayers than by not existing in a lot of cases (or practically that, since the effort that's involved would be pretty substantial for little benefit), and with the VCs involved, I don't think that's going to be practical for the company.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version