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
_______________________________________________
metacard mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/metacard
