Put a stack into a variable?

[Mike Bonner]

On the clipboard data question.. is it possible to compress the data in
memory on one end and decompress it on the other?  (talking about lc server
interactions)  Am now also wondering if it would be worthwhile to have rev
be able to load and decompress stack files on the fly.  As far as getting
stacks from a database, shouldn't it be possible to have a database
interface script, and have actuall stack files saved to a db that can be
requested with go stack "
http://wheres.the.stack.com/grabstack?which=stackname.livecode", query the
db and send the stackfile back intact?


On Sat, Jun 14, 2014 at 11:13 AM, Mike Bonner <bonnmike at gmail.com> wrote:

> The paste is how I did it in my little stack. Theres an old post about it
> here:
> http://forums.livecode.com/viewtopic.php?f=9&t=12876&hilit=objects+clipboarddata
> but I still haven't relocated the little stack thingy. Love the idea of
> copying a stack directly to a variable.
>
>
> On Sat, Jun 14, 2014 at 9:07 AM, Richard Gaskin <
> ambassador at fourthworld.com> wrote:
>
>> Thanks for the thoughts on this conundrum.
>>
>> Mark S' suggestion of restoring by saving the clipboardData["objects"] by
>> pasting is a good one and might be worth testing to see if this can be done
>> with LC Server, but since the clipboard version of a stack is nearly twice
>> as large as its native format I'm reluctant to spend much time with that
>> option in a setting already concerned with network latency.
>>
>> Similarly, Alain's suggestion of serializing to a text format (I tend to
>> use arrays for object serialization now that we have arrayEncode(); I'm
>> lazy so I let the engine do the parsing <g>) would also be a good one in
>> some contexts but suffers from the same limitation as the binary clipboard
>> data in terms of size.
>>
>> It's hard to beat the compact expression of stack data in the native
>> stack file format.
>>
>> At the moment I'm resigned to allowing file I/O in the app, rationalizing
>> the use of a cache folder for other benefits beyond the necessity of
>> sending stack files back to the server.
>>
>> For the future, I've submitted a feature request:
>>
>> Request: copy <stack> to <variable>
>> <http://quality.runrev.com/show_bug.cgi?id=12639>
>>
>>
>> Also relevant for those of you who make client-server apps, an older
>> request that would be useful in some scenarios by limiting file I/O to one
>> specific folder, prohibiting all other reads/writes:
>>
>> secureFolder
>> <http://quality.runrev.com/show_bug.cgi?id=867>
>>
>>
>>
>> --
>>  Richard Gaskin
>>  Fourth World Systems
>>  Software Design and Development for the Desktop, Mobile, and the Web
>>  ____________________________________________________________________
>>  Ambassador at FourthWorld.com                http://www.FourthWorld.com
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>