IDE and libUrl

Chipp Walters chipp at chipp.com
Wed Sep 8 17:51:44 EDT 2004


Dave,

Let me know if you need a place to host libURL. I've got plenty of 
server space.

-Chipp

Dave Cragg wrote:

> 
> On 8 Sep 2004, at 03:17, Richard Gaskin wrote:
> 
>> Some time ago Dave Cragg wrote:
>>
>> >> The version of libUrl (1.1a3) currently being distributed with
>> >> the Rev 2.5 beta (engine 2.6.1) is not backwards compatible with
>> >> earlier engines. This is because of syntax added to support
>> >> secure sockets in https URLs.
>>
>> Can older versions of libURL be used with newer engines (without 
>> support for new features, of course)?
> 
> 
> Yes.
> 
>>
>> 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?
>>
> I guess there will be a naming issue with the stack. (start using <???>)
> 
> The other issue I'm not so sure about is the potential syntax error when 
> using the newer libUrl with an older engine. (The problem syntax is 
> "open secure socket ...") I'm not sure exactly when/if the engine tries 
> to compile loaded stacks. If compiling is only done when a stack is 
> actually called (e.g. after a "start using") then it may be OK. But if 
> all substacks in memory are subject to script compilation, then there 
> may be a problem. (I guess I could check this out. :))
> 
> A thought. (Apologies if this is what you had in mind.) One approach 
> might be to make the libUrl stack simply a "loader" stack, with a single 
> "libraryStack" handler. The two "functional" versions of libUrl  would 
> be held in custom properties. The libraryStack handler would unpackage 
> the appropriate custom property and start using that stack. I just 
> checked if this is feasible, and it seems to be. Although it seems you 
> can't use "start using" directly on a custom property, you can "go" to a 
> custom property. So something like this might work:
> 
> on libraryStack
>   if "libUrl_" is not in the stacksInUse then
>     if versionLessThan("2.6.1") then
>       go invisible stack (the cLibUrl1_0_15 of me) ##contains stack 
> "libUrl_1_0_15"
>       start using "libUrl_1_0_15"
>       close stack  "libUrl_1_0_15"
>   else
>       go invisible stack (the cLibUrl1_1 of me)
>       start using "libUrl_1_1"
>       close stack  "libUrl_1_1"
>     end if
>   end if
> end libraryStack
> 
> function versionLessThan pTarget
>   put the version into tCurV
>   set the itemDel to "."
>   put 0 into tCount
>   repeat for each item tNum in pTarget
>     add 1 to tCount
>     if item tCount of tCurV < tNum then return true
>   end repeat
>   return false
> end versionLessThan
> 
> A problem here might be the size of the libUrl stack that has to be 
> carried around, but I guess the custom properties could be compressed.
> 
> Too complicated??
> 
> By the way, I just noticed that the libUrl pages on the new Rev website 
> are incomplete (no links to documentation or downloads). I'll check with 
> RunRev what they plan for this. However, it may be a good idea to have 
> the latest updaters posted elsewhere. On the Yahoo site perhaps, along 
> with the IDE. Or should I put together a separate download site? (or 
> both?).
> 
> Cheers
> Dave
> 
> _______________________________________________
> metacard mailing list
> metacard at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/metacard
> 


More information about the metacard mailing list