further incompatibilities with Rev

[Ken Ray]

On 10/9/04 12:19 PM, "J. Landman Gay" <jacque at hyperactivesw.com> wrote:

> On 10/8/04 2:31 PM, Richard Gaskin wrote:
> 
>> A new incompatibility has arisen between the 14-year-old MC IDE and the
>> latest version of Rev:  If you've used MC's Resource Mover to copy the
>> answer dialog, ask dialog, etc. into your stack, when you hand that
>> stack to a client to open in Rev they're greeted with an error dialog
>> warning them that stacks with those names are already in memory.
> 
> Is this really new? I thought it had been around since Rev 1.0.

No, Rev would just ignore it in previous versions. Only in 2.5 are they
actually bringing up the warning dialog.
 
>> While we've already spent more time than I would prefer accomodating
>> Rev's new behaviors, it may be simpler for us to simply accept being
>> forced into doing the extra work of integrating the Resource Mover with
>> the Standalone Builder as Rev does to accomodate its new behaviors.
>> 
>> What are the pros and cons of copying resources only into standalones?
> 
> If you mean removing the resource mover, then I'm not keen on doing
> this, as it eliminates the control we have that is the main reason we
> use the MC IDE in the first place. I'd prefer to just continue omitting
> these dialog stacks unless I'm building a standalone.

Agreed. Although the problem *for me* is that I'm working on projects that
need to have standalones rebuilt over and over again as the project
continues. This means that I would have to maintain two versions of my main
stack (or always copy it before I build it into a standalone), which is a
real pain in the ***.

> It's funny that we can have duplicates of the answer dialog in MC but
> not in Rev. Maybe the solution is to figure out why Rev can't do the same.

Rev *can* do it (they've been doing it up until 2.5 by ignoring the
conflict), it's just that now they've decided unilaterally to add this
incompatibility.

>> Of course the long-term solution is to get rid of the uniquely
>> Transcript limitation of stack name conflicts, as requested in
>> <http://support.runrev.com/bugdatabase/show_bug.cgi?id=1061>.
> 
> This would be ideal, for many reasons.

Agreed.

>> But in the meantime how can we best accomodate others in our workflow
>> who use Rev?

Good question. To that, I think we need to look at the different scenarios
and what would work best in each. Since sending stacks without resources or
sending standalones avoids this issue, there are only a couple of scenarios
I can see:

1) Stack with resources sent to someone who opens it in Rev:

     This sounds to me to be a relatively unique/rare circumstance because
one could just as easily create a standalone and send it to them and avoid
the issue (although it would add significantly to the download). In those
circumstances, perhaps having a "strip resources" utility that can be run on
our stacks prior to sending them out might do the job.

2) Main development done in MC, but the standalone building done in Rev:

     This is IMHO an even rarer circumstance because if someone is choosing
to develop in MC, why not build the standalones in MC? And if they *know*
they're going to build the standalones in Rev, why include the resources to
begin with? So this to me seems like something that's more of an "oops" that
we shouldn't need to make special accommodations for.

So IMHO, although it's annoying to get those errors, I wouldn't do anything
to change MC, other than perhaps including a "strip resources" utility for
those rare circumstances where #1 above applies.

Of course, I'm over here in my own little world, so I may not see the bigger
picture here... I'd be interested to know if there are other scenarios where
this becomes an issue...

Just my 2 cents,

Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: kray at sonsothunder.com