Re: IDE and libUrl
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
Re: IDE and libUrl
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 [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: IDE and libUrl
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 [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: IDE and libUrl
Dave wrote: 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?). I'll happily maintain a copy with docs at the MC IDE home page: http://groups.yahoo.com/group/MC_IDE/ -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: IDE and libUrl
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)? I plan to make future updaters aware of the engine version, and install the appropriate version. However, this might not be enough to keep confusion away. I'm not sure if the plan is to release new MC IDEs with each engine release (if so, then there mau be no problem), but I'm guessing people are hoping to be able to use the same IDE over a range of engine releases. There could be problems if people swap engines about liberally without being sure to have an appropriate version of libUrl in place. I can't think of an easy way round this problem right now. But if anyone has any thoughts, please let me know. 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 Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: IDE and libUrl
On 26 Jul 2004, at 20:42, Brian Yennie wrote: This reminds me of the warning the tools stack used to always give me when I got new beta releases of Metacard- that the version of the tools stack didn't match the version of the engine. Could we use this same sort of logic, and maybe add an extra line or two to the IDE to specifically check for a matching version of libURL? The user could of course ignore the warning, but at least they'd be likely to understand why their URL scripts were failing after receiving said warning... It may not be so straightforward. In the case of a new version of libUrl (= 1.1) with an old engine ( 2.6.1) I think a script error will pop up as soon as the engine tries to run/compile the script. I haven't checked out the details yet, but doesn't the engine start compiling scripts as soon as a stack is loaded? Cheers Dave ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: IDE and libUrl
Dave Cragg wrote: On 26 Jul 2004, at 20:42, Brian Yennie wrote: This reminds me of the warning the tools stack used to always give me when I got new beta releases of Metacard- that the version of the tools stack didn't match the version of the engine. Could we use this same sort of logic, and maybe add an extra line or two to the IDE to specifically check for a matching version of libURL? The user could of course ignore the warning, but at least they'd be likely to understand why their URL scripts were failing after receiving said warning... It may not be so straightforward. In the case of a new version of libUrl (= 1.1) with an old engine ( 2.6.1) I think a script error will pop up as soon as the engine tries to run/compile the script. I haven't checked out the details yet, but doesn't the engine start compiling scripts as soon as a stack is loaded? Yes, which has been evident when running with explicitVars on. Have you gotten my emails on that? I'd be happy to add the necessary declarations to libURL, but it would be very useful if I could use it when running with explicitVars (a requirement when I'm working on the MC IDE and a few other projects). -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: IDE and libUrl
Ah, right. Yes that would cause extra difficulty. With that said, should the IDE generally be doing something along the lines of: try start using stack libURL catch tErr answer error Error loading libURL... version conflict? end try And would that relieve some of the problems with any incompatible library, in general? It may not be so straightforward. In the case of a new version of libUrl (= 1.1) with an old engine ( 2.6.1) I think a script error will pop up as soon as the engine tries to run/compile the script. I haven't checked out the details yet, but doesn't the engine start compiling scripts as soon as a stack is loaded? ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: IDE and libUrl
On 27 Jul 2004, at 21:15, Richard Gaskin wrote: Dave Cragg wrote: On 26 Jul 2004, at 20:42, Brian Yennie wrote: This reminds me of the warning the tools stack used to always give me when I got new beta releases of Metacard- that the version of the tools stack didn't match the version of the engine. Could we use this same sort of logic, and maybe add an extra line or two to the IDE to specifically check for a matching version of libURL? The user could of course ignore the warning, but at least they'd be likely to understand why their URL scripts were failing after receiving said warning... It may not be so straightforward. In the case of a new version of libUrl (= 1.1) with an old engine ( 2.6.1) I think a script error will pop up as soon as the engine tries to run/compile the script. I haven't checked out the details yet, but doesn't the engine start compiling scripts as soon as a stack is loaded? Yes, which has been evident when running with explicitVars on. Have you gotten my emails on that? I'd be happy to add the necessary declarations to libURL, but it would be very useful if I could use it when running with explicitVars (a requirement when I'm working on the MC IDE and a few other projects). Oddly, no one has pulled me up about this. However, I've already added declarations for the recent (2.6.1 supportive) version. I'll try and add the same to the 1.0.15 version before it becomes final. Dave ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
IDE and libUrl
Hi all First, apologies for not making a bigger contribution to the IDE. (weak excuses about other commitments, new dog ate my e-mail, etc.) As an almost full-time user of the IDE, I'm grateful to everyone involved, and especially the great poohbah. Of course, there have been times when it looked like the whole IDE might fall prey to creeping eye candy (that modernistic splash screen for example, and older users probably think things started going south when the image icon changed some years back, was that you Rossi? grin). Anyway, to more serious things... 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. I plan to make future updaters aware of the engine version, and install the appropriate version. However, this might not be enough to keep confusion away. I'm not sure if the plan is to release new MC IDEs with each engine release (if so, then there mau be no problem), but I'm guessing people are hoping to be able to use the same IDE over a range of engine releases. There could be problems if people swap engines about liberally without being sure to have an appropriate version of libUrl in place. I can't think of an easy way round this problem right now. But if anyone has any thoughts, please let me know. Cheers Dave ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: IDE and libUrl
Brian Yennie wrote: This reminds me of the warning the tools stack used to always give me when I got new beta releases of Metacard- that the version of the tools stack didn't match the version of the engine. Could we use this same sort of logic, and maybe add an extra line or two to the IDE to specifically check for a matching version of libURL? The user could of course ignore the warning, but at least they'd be likely to understand why their URL scripts were failing after receiving said warning... The warning comes from the Home stack and not the IDE. The Home stack has never been altered since the project became open source. I could modify it but it's tricky, since I need to work on a virgin copy yet have the scriptLimits removed. I'll do that for the IDE version after the one currently in testing. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
