Revolution vs other solutions

MisterX b.xavier at internet.lu
Mon Jun 20 01:24:47 EDT 2005


I dont know if this can help but...

Rev is definitely the engine to use IMOHO - and on a PC as well.
Sure there's other solutions but time-to-finished-app in rev is
unbeatable...

Second, i've done a similar workflow and layout project long ago
in QX with their own tags that made the editing of the layout go
much faster than if i had used applescripts (AS). This reduced AS 
usage to the minimum (and damn if it wasn't the slowest language
back then even on PPC). 

There's different XML parsers out there but most are script based
as far as i know. You can make an external for it, you can use 
python libraries also. The choices are wide opened but you'll 
find that Rev is much much faster than HC ever was... 

The only problem i foresee is pdf files and how you might handle 
those. However there's plenty of commercial converters on the
Win32 platform to convert them to html, text, word, etc...

I dont know anything anymore about applescripts since i switched
to PCs (i missed just a tad for it's utility but there's vbs on
PCs which i've come to enjoy via runrev ;) IOWs, there's plenty
of choices out there for you but RunRev remains IMOHO the quickests
GUI of all ;)

Hope that's enticing enough

cheers
Xavier

> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com 
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of 
> Jesse Sng
> Sent: Monday, June 20, 2005 03:56
> To: How to use Revolution
> Subject: Revolution vs other solutions
> 
> Hi,
> 
> I'm writing this to all those who had made their own 
> evaluations to switch to Revolution for comment.
> 
> I've been monitoring this list and reading the discussions 
> for some time while doing some small evaluations of 
> Revolution from time to time as I was anticipating a rather 
> large project that would kick off in the near future.
> 
> Well after quite a bit of time, it looks like things are 
> definitely going to kick off real soon.
> 
> The project involves the automation of page layout from a set 
> of text data, integrating that with the workflow of a 
> graphics dept in a publishing company to build a final 
> document within Adobe InDesign.
> 
> This will involve tracking of graphics files (photoshop, 
> tiff, PDF), XML, text parsing, AppleScript integration with 
> InDesign and also building a publication database out of the 
> exported text data that will come to us. That will mean that 
> I will also need some sort of robust but lightweight database 
> solution that's integrated with Revolution and can support 
> multiple users.
> 
> This project is an entire REWRITE of a 15 yr old system that 
> I had delivered to them in 1990. The system was built around 
> QuarkXpress and I had written a plug in to do all that using 
> Quark's ver 2.x APIs. It's interesting that because of the 
> CEO's insistence that they do not upgrade to Quark 3.0 and 
> they milk every bit of the system for what it was worth, that 
> we have this desperate situation today that they must go for 
> a full rewrite as the system can no longer be upgraded.
> 
> It has been running since then and my last bug fix was somewhere in
> 1992 and they are still running on the old Quark 2.1x application. 
> They could not go past System 8.0 without breaking 
> QuarkXpress and that meant that they could not go with a 
> machine more recent than a Mac blue & white G3. Nothing can 
> move forward now without breaking one of the key components 
> and it's so long ago that none of the source code exists as 
> my original company has ceased to exist some years ago.
> 
> The fact is that I've been making most of my assumptions that 
> I will be building this using Revolution, integrating with 
> InDesign and Finder via AppleScript. I might also work with 
> them on integrating Photoshop and Illustrator/Freehand so 
> that everything works very smoothly.
> 
> At this point in time, I guess what I'm looking for is to 
> find out if there's any good reason for me NOT to use 
> Revolution. I've worked with Hypercard/Supercard since the 
> late 80s and am at home with xTalk, but used to write lots of 
> plug ins for HC/SC and also Quark though I much prefer not to.
> 
> Key considerations here are 1. commitment to move Rev from 
> PowerPC to Intel and I will probably be eligible for MacTel 
> seeding so this is something I want to test. 2. Stability - 
> it's nice not to have the system break because of my own code 
> but I and the users would be very helpless if the underlying 
> engine breaks for reasons beyond our control.3. the existence 
> of a pool of "smart friends", something that I'm already 
> certain exist on this mailing list.
> 
> I would probably need to look at some form of XML 
> manipulation library that is not memory based and is also fast.
> 
> I have considered using Supercard 4.5 and also RealBasic - 
> both of which I'm extremely familiar with but I have doubts 
> at this point in time as to whether SC can give me everything 
> I need plus it's checkered history makes me wary. RealBasic 
> can do the job, but somehow I won't have as much time to work 
> on this as I used to, plus I don't think I'm going to enjoy 
> the development experience quite as much as I've built 
> working apps with it before.
> 
> So I guess this is a rather strange request - does anyone 
> have a good reason why I should not use Rev at all? :-)
> 
> I'm being pulled out of retirement from software development 
> to do this thing and right now, I'm starting from scratch 
> including having to incorporate a company just to do this 
> thing. The users have searched for the last 5 or 6 years to 
> find someone who can replace the system and it keeps coming 
> back to me even though I tried to turn them down some years ago.
> 
> 
> Jesse Sng
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage 
> your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 



More information about the use-livecode mailing list