MC IDE v2.6b12 posted
Dave Cragg
dcragg at lacscentre.co.uk
Fri Dec 30 15:55:32 CST 2005
On 30 Dec 2005, at 20:55, Jan Schenkel wrote:
Hi Jan
>
> I don't know if you've considered the following
> "trick":
> --
> try
> do "open secure socket to tHost"
> catch
> answer "This version of the engine does not support
> secure connections." & return & "Do you want to open a
> regular socket instead?" with "Yes" or "No"
> if it is "Yes" then open socket to tHost
> end try
I'd considered something similar (using "do"), but didn't try.
One reason is that libUrl development has been "sponsored" (paid for)
by Run Rev, and using "do" seemed like a sub-optimal solution when
Rev IDE users are not affected by this issue. (The latest libUrl
version is distributed with the Rev engine/IDE combo, and any libUrl
updaters are smart enough to update to the appropriate version.)
Another reason is that I expect that other syntax issues like this
will arise in future, and things could become very messy if I tried
to support all engine versions in libUrl. (It's messy enough already
in trying to support variant socket behavior over different engine
versions, but this was the first "new syntax" issue.)
It would be easy enough to make a separate version for the MC IDE,
but I think this might lead to other problems down the line.
OK. You've got me thinking.
One possible solution might be to strip the libUrl substack out of
mctools, and place it in a "libraries" folder that gets distributed
with the IDE. In this "libraries" folder, there would be a "libUrl"
subfolder, and within that, a "liburl_pre2.6.1" and a
"liburl_standard" folder. These two folders would contain the
appropriate version of the libUrl stack (both with a stack name of
libUrl). Then in the mctools stack, in its initialization, it could
"start using" the appropriate libUrl stack. (And perhaps set its
stackfiles to include a suitable entry.) I'm not sure how the
"resource mover" does its stuff, but I suspect this would work or
could be made to work too.
Any thoughts? I'd be happy to take a look at this unless anyone can
think of any gotchas.
Cheers
Dave
More information about the metacard
mailing list