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" ar
Hello Björnke,
We probably need to get in mind that desktop apps stacks and server's stacks
are not dedicated to do the same jobs !
On the left, desktop apps stacks are handled in RAM as long running processes
and this give us lots of possibilities, sockets management included. If you
really s
On 9 Aug 2011, at 19:20, Pierre Sahores wrote:
> Hi Björnke,
>
> FOR ME The main goal of using the server's stack component is to let us
> store our code as password protected libraries
I fixed your point above. The problem is exactly that mindset. This time "your"
user case was supported.
Hi Jacques,
Stephen (Brancard) noticed some days ago that in double clicking any server's
stack from within our FTP browser window, the stack will be directly opened in
our LC desktop IDE. In this way, we can edit our code exactly as if the stack
went stored locally and we can use the IDE debbu
I agree, Pierre,
Nice job from RunRev guys. Now the On-Rev client has to be updated, and all
will be perfect.
Jacques
2011/8/9 Pierre Sahores
> Hi Björnke,
>
> The main goal of using the server's stack component is to let us store our
> code as password protected libraries instead of storing i
Hi Björnke,
The main goal of using the server's stack component is to let us store our code
as password protected libraries instead of storing it in unprotected flat text
.irev components. This server's stack component is useful each time we need to
install our LC-server solutions on clients se
Hi Björke, i understand your state of mind, which I do share.. sometimes! I
take the position of using what is usable, what actually work; I took time
to test these stacks because it was strategic for my plans. And I adapted my
strategy to fit what works fine now.
On the other hand, I would really
Quite simply, any new feature RunRev implements is a patch, as in patched up
clothes. RunRev lacks the manpower (but not the dedication) to create fully
working groundworks, like a full implementation of stacks for all platforms, a
native GUI for iOS, native table fields or allowing all objects
stephen barncard wrote:
Again, Robert I have to disagree with you about this. You seem to feel
shortchanged somehow with the way stacks work on the server, yet it's really
doing all it can do in that environment.
What else would you want a stack to do on a server? The GUI has to be
created in H
Again, Robert I have to disagree with you about this. You seem to feel
shortchanged somehow with the way stacks work on the server, yet it's really
doing all it can do in that environment.
What else would you want a stack to do on a server? The GUI has to be
created in HTML - it's a web browser y
I started to work on a project involving server stacks and had to stop full
stop... here is why :
Servers stacks are designed as SCRIPT CONTAINERS, allowing to password
protect scripts on the server and develop libraries. Card creation, field
creation and navigation are crippled and do not allow
Thanks Stephen for testing and I hope you can propagate these info.
It would be great to have the official position of the "mothership" team :
1) regarding the creation of fields :: is that a choice that will be
followed, or is it a bug that is bound to be corrected?
2) regarding saving stacks
Robert, on my installation of LIvecode Server, everything you say I've found
to be true, except that I was able to use my preferred suffix .rev instead
of .livecode.
I'm impressed that there are so many things are *right* and *up to date* in
the docs lately, imho. On this new stuff, there's sure
Stephen Barncard-4 wrote:
>
> GUI objects are not applicable in a server environment.
>
Yes indeed, so I would not expect to create a button in the server
environment,
but as I pointed out, fields are NOT ONLY part of the GUI, theyr'e are ALSO
a very common DATA holder.
as an example, fields ca
Why would one want to create a field one can't use anyway?
There are probably a lot of little things in LCS that haven't been trapped
as errors or to fail silently yet, but common sense can be a guide to "what
is" and "what isn't": GUI objects are not applicable in a server
environment.
Reading f
revServer memo :: focus on : server STACKS
1) USING an existing stack
go stack myStack.livecode :: make sure the correct file extension is
used
effect :: sets the correct message path putting mystack ahead in the
path
getting values and setting values
Hi, saving a stack works fine in my case too. And this is important to my
view.
But create field does not work.
warning :: COHERENCE WITH revServer online
Dictionnary --
1) Create stack and save are greyed in the docs but actually work on my
on-rev implem
Odd results, in your case. I have had no problem creating and saving a stack
with LIvecode Server 4.6.3, as well as saving and load multidimensional
custom properties. Creating cards is no problems as well.
here's my create stack code, be it simple as it is, that worked for me on
LIvecode Server 4
Why create and save stacks? To use stacks in publishing process :: "one to
many", where one author or a reduced number of persons update some
hierchical and finally structured datas. That's what I hope I can now do
with these stacks long awaited!
Relationnal database is of course much needed in a
I would love to use stacks instead of files. Millions of sites work just fine
saving stuff into files, despite them not being multi user save or anything
weird like that.
More importantly, stacks should work like stacks everywhere, and not partially
on mobile, partially (but different) as revl
Hi,
I guess I was just wondering how the new feature of being able to use stacks
could be useful in designing web applications. I was not really thinking of
multi user sites but something where one user is updating a blog or static
content or something like that.
As I was thinking about this
Why create stacks when LiveCode Server can manage data via text files or
databases - the orthodox data storage options for multi-user server
environments, which come complete with robust security models?
If the data is structured and suits a database approach, the inherent data
storage aspects
in Koob
To: use-revolut...@lists.runrev.com
Cc:
Sent: Sunday, August 7, 2011 3:15 PM
Subject: Re: [Server] create stack trouble
I have added an enhancement request to the QCC to have 'save stack'
implemented on LiveCode Server, Report #9664
Is there another way to save a stack that I am missin
I have added an enhancement request to the QCC to have 'save stack'
implemented on LiveCode Server, Report #9664
Is there another way to save a stack that I am missing?
Is there a reason why allowing LiveCode server to save stacks would not be a
good idea?
I see it could be a way to store data w
I had another thought. What if you added your stack to an existing stack
that is already saved on the server as a substack? I have an existing
stack "libstackmain.livecode" in the directory that I could add substacks to
so I tried the following:
Creating stack: " & tNewstackName & ""
create sta
Hi
I tried this on a third party install not on On-rev.
I tried the create stack command and then to see if a stack was indeed
created I used the openstacks command.
put "newcompany" into tNewStackName
put "Creating " & tNewstackName & ""
create stack tNewStackName
repeat for each line thislin
Andrew,
I tested it with all the permissions on the file and the folder as their most
lenient. It still didn't work.
Mike
--- On Fri, 8/5/11, Andrew Kluthe wrote:
From: Andrew Kluthe
Subject: [Server] create stack trouble
To: use-livecode@lists.runrev.com
Date: Friday, August 5, 2011, 12:34 P
27 matches
Mail list logo
