Thanks Jaque but it looks very much like revServer, the LiveCode architecture
and IDE simply aren't designed to support development and deployment of thin
client, standards-based web applications.
If revServer is just a CGI in that scenario, I might as well use PHP - which is
live, recognised,
Yes Bob, that's pretty much exactly how I was expecting the LiveCode sever
deployment to work. Develop in the IDE, create a 'server stand alone' and
deploy - the server then interprets the proprietary stacks and controls as
standard HTML+CSS pages to serve to the visitors browser.
That is how
On 2/18/11 9:57 PM, Bob Cole wrote:
Read Keith's intended use of revServer, it reminded me of an old
program called LiveCard distributed by Heizer Software in the late
1990's. Great name for a program, eh? I was fascinated by the idea
when it came out but I didn't know enough about servers and th
This message bounced back to me because I sent it from an e-mail address that
isn't my normal one.
Sorry if it double posts.
Bob
On Feb 18, 2011, at 10:10 PM, Bob Cole wrote:
> Here is the old LiveCard user manual:
> http://boredzo.org/stuph/LIVECARD%201.1%20User%20Manual.pdf
> Bob
>
> On
Read Keith's intended use of revServer, it reminded me of an old program called
LiveCard distributed by Heizer Software in the late 1990's. Great name for a
program, eh?
I was fascinated by the idea when it came out but I didn't know enough about
servers and the internet back then.
Anyway, I Goo
On 2/18/11 7:52 PM, Alex Tweedly wrote:
I meant irev scripts. I want to have some functionality be hidden from
people with access to the scripts on a web site (say, a funciton that
uploads things to my ftp site, so contains my ftp username and password).
If I was using CGI I could password prot
If you have the correct libraries on the server, you can create a
linux standalone and then run it as CGI that is as secure as it
gets.
On Fri, Feb 18, 2011 at 11:52 PM, Alex Tweedly wrote:
>
> I meant irev scripts. I want to have some functionality be hidden from
> people with access to th
I meant irev scripts. I want to have some functionality be hidden from
people with access to the scripts on a web site (say, a funciton that
uploads things to my ftp site, so contains my ftp username and password).
If I was using CGI I could password protect that stack - but then the
other p
On 2/18/11 6:48 PM, Alex Tweedly wrote:
I don't find the feature parity close enough that it "is easily worked
around by copying the script to a text file and including it that way".
Some of the things that are "best practice" (IMO) for stack scripting
just don't work when the script is saved t
I don't find the feature parity close enough that it "is easily worked
around by copying the script to a text file and including it that way".
Some of the things that are "best practice" (IMO) for stack scripting
just don't work when the script is saved to a text file and included:
- priva
Jacque wrote:
> So that would allow you to store all your images in a single stack instead of
> offloading them
> separately to an images folder on the server.
Besides that, when RevServer finally supports stacks as promised, you should
also be able to do things like image manipulation, which
On 2/18/11 4:33 PM, Björnke von Gierke wrote:
Wow you had some scary complicated cgi setup :D
Yeah. :) The goal was to show a rotating random image inside a static
web page, with a refresh every few seconds. Using the old CGI interface,
there wasn't a good way to do that without an i-frame un
Wow you had some scary complicated cgi setup :D
I always had one cgi to rule them all, and then images and sql in the
background. sometimes files for content (not for templates). I planned on using
modrewrite to fake pages out of that, but normally i'd pass on that due to
lazy. For debuging I u
On 2/18/11 1:41 PM, Keith Clarke wrote:
Thanks for the clarification Jaque. So, I already had the current
LiveCode server before I 'invested' in the revServer myth.
Depends on what we're talking about. You asked about feature parity; in
that respect, 3.5 and 4.x are similar as far as what you
Thanks for the clarification Jaque. So, I already had the current LiveCode
server before I 'invested' in the revServer myth. Live and learn! ;-)
On 18 Feb 2011, at 19:19, J. Landman Gay wrote:
> On 2/18/11 9:30 AM, Keith Clarke wrote:
>> Thanks for reframing the problem Bjoernke!
>>
>> Actuall
Thanks for persevering with me Jaque (et al). I think I get the subtlety now.
RevServer will not be a web server that interprets deployed stacks' UI elements
as web pages. Stacks deployed to revServer are purely a convenient container
for server-side scripts - to avoid the need to save the scri
On 2/18/11 9:30 AM, Keith Clarke wrote:
Thanks for reframing the problem Bjoernke!
Actually, I have the 3.5 CGI but as I arrived on planet LiveCode
after version 4, I'm concerned about just how limited my palette
would be with v3.5 engine and UI controls. This is especially the
case as I've used
On 2/18/11 3:10 AM, Keith Clarke wrote:
Thanks for the clarification Jaque.
So, my expectations for the shipping version weren't too far off - as
it would allow development using stacks (as with the desktop apps)
and upon deployment to the server, a standard browser would be able
to interact wit
Robert, Sorry, I had moved focus from considering the user experience of the
developed application to the development environment and how to shove 4.5.3
prototypes into a limited 3.5 environment. As this thread is far from its
origin, I'm starting a new thread, with more appropriate question.
Thank you all.
Yes, the old CGI engine Rocks, but what about the new one?
Besides that we can not use the stacks, any of you tried to install
the Pre-release 2 of Rev-Server ? Is it reliable? Is it stable?
I wrote some scripts for the on-rev server. They works fine.
As far as you know, is it a goo
On 18.02.11 at 15:30 + Keith Clarke apparently wrote:
Thanks for reframing the problem Bjoernke!
Actually, I have the 3.5 CGI but as I arrived on planet LiveCode
after version 4, I'm concerned about just how limited my palette
would be with v3.5 engine and UI controls. This is especially t
...yeah, so do AC/DC but that doesn't help me develop standards-based web apps,
either! ;-)
On 18 Feb 2011, at 15:28, Jim Sims wrote:
>
> On Feb 18, 2011, at 4:22 PM, Andre Garzia wrote:
>
>> yeah but keith does not like the old CGI engine, it doesn't serve him well.
>
>
> The old CGI engin
Thanks for reframing the problem Bjoernke!
Actually, I have the 3.5 CGI but as I arrived on planet LiveCode after version
4, I'm concerned about just how limited my palette would be with v3.5 engine
and UI controls. This is especially the case as I've used several plug-ins and
externals in my
On Feb 18, 2011, at 4:22 PM, Andre Garzia wrote:
> yeah but keith does not like the old CGI engine, it doesn't serve him well.
The old CGI engine Rocks!
sims
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscr
yeah but keith does not like the old CGI engine, it doesn't serve him well.
:-/
2011/2/18 Björnke von Gierke :
> I guess it's: "How to use RevServer in tandem with stacks?"
>
> And the answer is old style rev cgi. Every customer is entitled to mail
> runrev and demand the old cgi engine from th
I guess it's: "How to use RevServer in tandem with stacks?"
And the answer is old style rev cgi. Every customer is entitled to mail runrev
and demand the old cgi engine from them. I suggest every customer should do
that.
At least that is something one can actually do.
On 18 Feb 2011, at 14:5
Andre,
My primary target market involves existing users of SaaS solutions, where any
installation of plugins or net-savvy windows stand-alones (however good) would
be a really hard sell.
Indeed, during market-testing discussions with potential customers before I
decided on my development platf
Keith,
Talking about RevLets, how is your experience with them under windows?
do you think your user base would install the plugin with no fuss?
andre
On Fri, Feb 18, 2011 at 7:10 AM, Keith Clarke
wrote:
> Thanks for the clarification Jaque.
>
> So, my expectations for the shipping version were
Thanks for the clarification Jaque.
So, my expectations for the shipping version weren't too far off - as it would
allow development using stacks (as with the desktop apps) and upon deployment
to the server, a standard browser would be able to interact with the
UI-specific, stack pages on the s
Note that there's also need for having the stacks cards and most importantly
graphics and images being accessible. because that's an easy and proven way to
create images for the web via the export and import commands.
On 17 Feb 2011, at 20:38, J. Landman Gay wrote:
> There have been requests
On 2/17/11 12:03 PM, Keith Clarke wrote:
However, isn't this 'thick client' web application architecture,
(with the proprietary revlet download and requisite local
machine/browser support by a rev plug-in) only one revServer
scenario?
Yes.
According to the RunRev product page, it is still b
Jaque,
Thanks for the explanation and the links (bookmarked for further study).
However, isn't this 'thick client' web application architecture, (with the
proprietary revlet download and requisite local machine/browser support by a
rev plug-in) only one revServer scenario?
According to the R
On 2/17/11 3:06 AM, Keith Clarke wrote:
I bought the server deployment in the expectation that I could take
the same set of stacks I would use for a desktop app development and
(perhaps with a few modifications) simply deploy to revServer to
create a web application, with the UI elements 'automa
Andre, You're absolutely correct that my expectations were too high. I wasn't
complaining but just explaining why I wasn't using revServer yet and therefore
couldn't address Paulo's question. ;-)
The revServer product description in the store
http://www.runrev.com/products/server-deployment/ re
On Thu, Feb 17, 2011 at 7:06 AM, Keith Clarke
wrote:
> I bought the server deployment in the expectation that I could take the same
> set of stacks I would use for a desktop app development and (perhaps with a
> few modifications) simply deploy to revServer to create a web application,
> with t
Thank you Keith.
Actually I had much greater expectations too. I have several stacks
working as CGI with the revolution engine and I can not re-use them in
rev-server.
However I could fix the code of some stacks and put it in a .irev
file, provided the rev-server will work properly.
Many thanks
Pa
Paolo,
Sorry, I can't answer your question as whilst I have revServer installed, it is
currently unused, as my expectations of it were far greater than a CGI engine.
I bought the server deployment in the expectation that I could take the same
set of stacks I would use for a desktop app developm
Keith,
thank you very much. This is really helpful.
Still I have some questions about rev server:
Generally speaking, is the rev-server (Pre-release 2) reliable for
professional services ?
The "Server Deployment Pack" (Pre-release 2) install the same
rev-server version as the one running in the
Keith,
This is fantastic. Thank you.
Bill Vlahos
_
InfoWallet (http://www.infowallet.com) is about keeping your important life
information with you, accessible, and secure.
On Feb 16, 2011, at 2:08 PM, Keith Clarke wrote:
> Hi folks,
> I promised to publish some notes on the ab
ohhh thanks!
On Wed, Feb 16, 2011 at 8:08 PM, Keith Clarke
wrote:
> Hi folks,
> I promised to publish some notes on the above - new to blogging as well as
> LiveCode and OSX server, so I hope they help a bit:
> • OSX Server vs Regular OSX considerations:
> http://blog.clarityforsuccess.com/2011
Hi folks,
I promised to publish some notes on the above - new to blogging as well as
LiveCode and OSX server, so I hope they help a bit:
• OSX Server vs Regular OSX considerations:
http://blog.clarityforsuccess.com/2011/02/revserver-on-osx-server-vs-osx.html
• Configuring OSX Server for revServer
41 matches
Mail list logo
