IDE and libUrl

[Robert Brenstein]

>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