[Server] create stack trouble

[Sivakatirswami]

jan wrote:

>  Storing data is an enticing idea, but flawed: stacks are not a multi-user data storage infrastructure.

You are of course right  for multi-user scenarios.

but I beg to differ in cases where

a) the data is read only for web delivery or for the majority of users
b) the "editors" are few to one; possibly even "just for me, my brother 
and one hired hand"
c) you need to be able to massage that information easily independent of 
a web connection.
d) You need to be able to ship the "corpus" of data to someone else to 
edit it.

Think of the stack as, as a document with 3000 pages (cards), a 
"manuscript" if you will and you want someone to work on it, pass it 
around, put it on a thumb drive, build cool widgets to massage or 
process the data. That's a miniscule amount of data from one point of view.

Recently Andre is helping us build a new web site and we are using MySQL 
for the data on the back end. We don't have much choice because 
rev-server does not support stacks, and RevIgniter has great dBase support.

That said... if RevServer/RevIgniter actually supported "start using" I 
would, now after watching our development process, seriously think about 
doing what we are doing now with stacks.

When I look at the overhead that comes with an SQL framework, I have to 
shake my head, and, at least in house I will always revert to shared 
stacks on our LAN server here, setting up a semaphore to lock stacks in 
use is trivial...even though I could open up MySQL data base on our OSX 
server, the "software at the speed of light" paradigm suddenly becomes 
"Mucking along with SQL...one foot cut off and one arm tied behind your 
back."

if all you know is LiveCode and you are spoiled by the speed with which 
you can handle and process data with stacks. SQL Yoga and the Data Grid 
are great, but so complex and vulnerable to breakage ) and so hard to 
debug....We even reverted here to table fields for some desktop clients 
that talk to the new MySQL dbase... How easy is it to drop a blob of tab 
delimited txt into a fld and talk to that? Now if I were getting that 
data from a stack on the web server, how easy would that be?

So I would heartily endorse use of stacks for small data sets. At the 
very least you will be proto-typing at "light speed" and when your need 
to move up to a SQL database reaches critical mass, you will have ironed 
out your use cases with some precision well in advance of building your 
table structures, vs  build the SQLBase from the get go, based on a 
"functional specifcation" and then face multiple iterations because, no 
matter how well you think you have your spec nailed down... things 
change... if you were using a stack based scenario, the implementation 
of design change would be  trivial compared to what you have to go 
through with a database on the back end and the API to talk to it.  then 
later, porting that to MySQL or PostGreSQL would be a "Piece of Cake" 
because you would know exactly where you were going.

Just my two avocados from Hawaii (coming in bushels this time of year)

Sivakatirswami





On 8/7/11 4:26 AM, Jan Schenkel wrote:
> I couldn't help but wonder why you wanted to save stacks from LiveCode Server.
> The important part of this support is the ability to share business logic between desktop, mobile and server applications.
>
> Storing data is an enticing idea, but flawed: stacks are not a multi-user data storage infrastructure.
> Invocations of your .lc script from multiple clients may come in any order, and some processing may take longer.
> And what if a user is impatient, hits the back button in his browser and pushes the same data again?
>
> Stick with databases for storage, especially in multi-user scenarios - it's what the things were built for :-)
>
> Jan Schenkel.
> =====
> Quartam Reports&  PDF Library for LiveCode
> www.quartam.com
>
>
>


-- 
Om Shanti
Sivakatirswami

Kauai Aadheenam