Specify file download path with irev/revignitor

Tim Selander selander at tkf.att.ne.jp
Sun Mar 25 06:06:04 EDT 2012

Stephen, (and Jacque),

Thanks again for your reply -- got it about the browser 
controlling downloads for security reasons.

Also, some very good information here. I hadn't known about 
StackRunner and your idea of a thin client is great -- I can 
probably pre-install it on the MP3 players before we send them 
out. Simply have folk plug the players into the USB port, and 
when it shows up on the desktop, launch the client to make sure 
they have this month's content.

(Rather than music, we're doing lectures and seminars, etc. Savvy 
users are already handling their own downloads and ipods. This 
project is an attempt to wean our non-techie customers off mailed 
out CDs... gotta be something grandpa and grandma could handle.)

Also great link to the LiveCode Server docs -- I did not know 
about those! I got the freebie version of RunRev when I signed up 
for hosting at on-rev and have been working with that and it's 
user manual...

Appreciate the help.

Tim Selander
Tokyo, Japan

On 3/25/12 11:13 AM, stephen barncard wrote:
> Ah - well that's the thing - the security features of web browsers strictly
> don't allow control of the user's machine from the server side - that's
> what those warnings for the user for plug-ins like flash and the livecode
> plug-in are about. Changing stuff on a remote machine by a server is
> forbidden for users' protection - otherwise the web would be unworkable
> thanks to the criminal element. Those same protections are built-in by
> design for Javascript on the browser side for the same reason. Hence the
> invention of the Livecode plug-in.
> That's why I thought you had a 'thin' client on the user's side that could
> do what you want; your mentioning of "sending out" players.  You could do
> this with a Livecode plugin, but that would require users to install
> something on their machines anyway, and the future of this plugin has not
> been defined lately, hence the recent discussions online. I feel a thin
> client can give a better UI experience anyway and a lot easier to maintain
> and support.
> Your comment about the online documentation of Livecode server is correct -
> a lot of new info is available with the version notes of the latest version
> (5.0.2), but I get those through my involvement as a purchaser of the
> server product to run on my own web host. I assume you've seen what the
> Runrev site offers:
> http://www.runrev.com/developers/documentation/server/
> These limitations that web browsers have do not diminish the coolness of
> Livecode server; it just requires being open to do it another more secure
> way. You never want to do stuff without the permission of your users, that
> would definitely creep them out.
> Depending on the scope of your project, number of users, etc, is it
> possible you could do this entirely 'in the cloud'? That way you could
> control the addition and deletion of files, giving each user their own
> space for files, and provide the player in a browser.
> Otherwise I'd suggest you build a thin user client for her to download and
> live on her machine. Or possibly use a 'splash screen' approach where a
> small compiled application would hold the basic livecode 'stuff', and a
> script could do a
> go URL "http://musicsource/playerstack.lc"  on startup
> thereby loading your latest stack version of your player that could be
> 'updated in the store' anytime you wish, as that stack would live on your
> server. Yet this client could have access to any folder your user has
> access to on her machine. This thin client can then easily manage the audio
> files in the user-selected (or default) folder.
> I've done this myself as a convenience to run many utility stacks that I
> store on my server, and run on one of my several machines, a kind of
> network based Livecode stack player. Mine is a network variation of Ken
> Ray's Stackrunner.<http://www.sonsothunder.com/devres/livecode/downloads/StackRunner.htm>
> It sounds like a cool project - being open and controlling expectation of
> what can be and can't be done is the key, work around those limitations
> (that everyone else has to deal with), and move forward. Livecode gives us
> many ways to create the solution to our problems.
> hope this helps.
> On 24 March 2012 17:00, Tim Selander<selander at tkf.att.ne.jp>  wrote:
>> Thanks for your reply, Stephen.
>> Sorry for not being clear. I'm wanting to do this from a web page hosted
>> on the on-rev.com site, using the<?irev>  scripting language with the
>> revignitor framework. The "clients" have no LC client installed other than
>> a web browser.
>> One of my frustrations of using on-rev and the scripting language is that
>> there does not seem to be any documentation clearly showing what LC
>> features are _not_ available through the server scripting language. But it
>> is still far easier for me to use than php.
>> I have tried, of course, setting the full path/filename of the files I
>> want to download, but it has not worked correctly so far... hence the post!
>> Many thanks,
>> Tim Selander
>> Tokyo, Japan
> Stephen Barncard
> San Francisco Ca. USA
> more about sqb<http://www.google.com/profiles/sbarncar>
> _______________________________________________
> 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

More information about the Use-livecode mailing list