I'd propose that we do with libURL what we did with the Standalone Builder: have two versions included in the IDE, and use the version appropriate to the engine being used in that session.
Can anyone think of a downside to that?
For the sake of simplicity I like being able to use one IDE build across all versions of the engine from the time the IDE went open source going forward. There may be a time when that goal is no longer supportable, but as long as it is I think it's worth doing.
Any downsides to the approach for libURL proposed here?
-- Richard Gaskin
I think it is a good idea to have two different versions of libURL available if that is needed to support larger range of engines.
The only addition to consider is being able to query the version number of the currently used one. May be it is already supported.
This actually could be a common feature of all components (mainstacks as well as substacks) of IDE. In my opinion, aside from the overall release number, each component should have its own version number. Rather than creating a function for this, we could agree on all stacks having a custom property, for example, mcStackVersion, that could be queried by whatever means one desires. If we want to be more sophisticated, we could have a set with version, date, author, changes.
By the way, when implementing both versions, are we going to have libURL inited at startup now or the current practice of each urlLib call librarizing it again will continue? The copy I got lately from Chipp is an installer with separate buttons for Rev and MC, so patching the code with missing libraryStack handler could be done in the installer. I am sure the author will agree with that.
Robert Brenstein _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
