Rev Stacks for "tiny" read only backend web dBases

Andre Garzia soapdog at
Fri Feb 11 13:59:00 CST 2005


if you're only reading, I think there will be no problem but beware of 
writing records when someone is reading them. I don't know if start 
using can travel networks, but sure it can travel folders, so you might 
be in good hands. Anyway, if you're dealing with such simple data have 
you considered simple XML files or even simpler, a text file?


function saveGlossaryToFile pGlossaryArrayA
	combine pGlossaryArrayA by numToChar(4) and numToChar(5)
	put pGlossaryArrayA into url "file:../html/books/master_lexicon.txt"
end saveGlossaryToFile

function loadGlossaryFromFile
	put URL "file:../html/books/master_lexicon.txt" into tGlossaryArrayA
	split tGlossaryArrayA by numToChar(4) and numToChar(5)
	return tGlossaryArrayA
end loadGlossaryFromFile

PS: I just created both funcs on the run as I typed this answer...


On Feb 11, 2005, at 5:45 PM, Sivakatirswami wrote:

> For a small amount of data to be delivered on the web e.g. 1000 
> records or less; in this case, word definitions of a glossary. where 
> the record has only two pieces of data
> --word
> -- definition,  
>  am wondering if a back end revolution stack can serve us?
> Since input will be by a single admin individual, access would be read 
> only. It's so simple, I'm not sure we need a macho PostGreSQL dbase 
> for this and a Rev Stack would be so easy-portable. I can have someone 
> working on a stack on his own machine... then just move it to the 
> server how efficient is that... very...
> The question would be: are there any read access concurrency issues in 
> such a web app context?
> Anyone else doing this? what's your experience?
>  if a cgi calls
> "start using stack "../html/books/master_lexicon.rev"
> ... does that mean another person hitting the same CGI within 
> milliseconds will have a problem?
> Thanks
> Sivakatirswami
> _______________________________________________
> use-revolution mailing list
> use-revolution at
Andre Alves Garzia ð 2004 ð BRAZIL

More information about the use-livecode mailing list