subject:"Calling a livecode executable \-ui from LC server and get back a result."

It is only editbin.exe you need which might floating around online on its own 
somewhere...

Also I think the subsystem is specified in a byte in the header of a PE 
executable so could be twizzled with a script that modifies that byte...

Probably an easy exercise for anyone who likes poking around in binary formats 
(search for windows PE format online should give the appropriate specs).

Warmest Regards,

Mark

Sent from my iPhone

> On 5 May 2017, at 19:11, Malte Brill via use-livecode 
>  wrote:
> 
> Mark,
> 
> thanks a lot for taking the time to explain things here! Very valuable 
> information! I will certainly give it a try. Just need to install Vis Studio 
> :-)
> 
> While you are here: would you think, that a call to cURL should work on 
> Windows server? For the life of me I can not get it to, even for the simplest 
> calls. Always comes back with an out of memory error, which I believe is a 
> lie in the status code. 
> This is actually what started the experiments for me. I will give Alex 
> suggestion a try also, as this might be a workaround that might actually 
> work. And all that, just because some 3rd party insists on cookie 
> authentication for a Webservice where I would need to get the Headers back 
> from a post. *sigh*
> 
> Thanks all!
> 
> Malte
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Calling a livecode executable -ui from LC server and get back a result.

Ah!  Now the light comes on. This example, with the background provided 
in your previous post, make it all come together.


Thanks!

--
 Richard Gaskin
 Fourth World Systems


Mark Waddingham wrote:

> Just an update on my previous post. I did the following:
>
> Took a community standalone engine from inside an installed LiveCode
> distro on Windows and copied to the desktop.
>
> Tried (from Command Prompt):
>
>Standalone.exe -ui
>
> Noticed that I just got a newline in the console, and nothing else.
>
> Did:
>
>EDITBIN.EXE /SUBSYSTEM:CONSOLE Standalone.exe
>
> Then repeated the same command (Standalone.exe -ui) and got:
>
> ERROR: Initialization error - no stackfile to run
>
> Where I would expect - in the console.
>
> Then I created a simple livecodescript file:
>
>script "foobar"
>on startup
>  write "foobar" to stderr
>end startup
>
> Then did:
>
>Standalone.exe -ui foobar.livecodescript
>
> And got 'foobar' in the console I ran it from, and the console did
> nothing more (as standalone engines don't quit unless you explicitly
> close all stacks, or 'quit') until I did Ctrl-C. At which point
> control returned to the console.
>
> So - I think the EditBin suggestion will do as you want - and let you
> create a standalone (built or unbuilt) which runs like a normal
> console command so you should be able to get its output in shell() or
> from open process.
>
> Hope this helps!


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Calling a livecode executable -ui from LC server and get back a result.

Roger Eller wrote:

> Have you considered running a faceless Desktop app as a service,
> having it watch for a socket message...

Pierre Sahores and I have experimented with a wide range of socket 
servers*, with some very promising results.

That said, our independent tests seem to arrive at the same conclusion:

The execution speed of LC does compare favorably with other scripting 
languages, but best when used behind a load balancer.

Even though HTTP can be a fairly sparse protocol, without much more 
required overhead than you'd need for just about any general-purpose 
socket comms, coupling that directly with the processing of each request 
within a single engine instance creates bottlenecks.

So I like to think of socket servers in LC as very capable solutions for 
"Nanoservices": similar to microservices in scope, but suitable for 
workgroups and other relatively low-traffic environments.

Having multiple instances as workers behind a server front-end like 
NginX can be quite good, but doing both roles - socket I/O and 
processing - is a bit much to put on a single-threaded scripting engine 
like LC, at least in production environments set up for (hopefully) 
scaling public access.

That said, for workgroups there's much that can be done quite 
wonderfully with LC taking on the role of an HTTP daemon.

And as a pool of workers behind something like NginX it can stand up 
well against many alternatives scripting options, even in production 
environments.

* Sampling of related links from the archives:

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web

 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Calling a livecode executable -ui from LC server and get back a result.

Mark,

thanks a lot for taking the time to explain things here! Very valuable 
information! I will certainly give it a try. Just need to install Vis Studio :-)

While you are here: would you think, that a call to cURL should work on Windows 
server? For the life of me I can not get it to, even for the simplest calls. 
Always comes back with an out of memory error, which I believe is a lie in the 
status code. 
This is actually what started the experiments for me. I will give Alex 
suggestion a try also, as this might be a workaround that might actually work. 
And all that, just because some 3rd party insists on cookie authentication for 
a Webservice where I would need to get the Headers back from a post. *sigh*

Thanks all!

Malte


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Calling a livecode executable -ui from LC server and get back a result.


Hi Malte,

Just an update on my previous post. I did the following:

Took a community standalone engine from inside an installed LiveCode 
distro on Windows and copied to the desktop.


Tried (from Command Prompt):

  Standalone.exe -ui

Noticed that I just got a newline in the console, and nothing else.

Did:

  EDITBIN.EXE /SUBSYSTEM:CONSOLE Standalone.exe

Then repeated the same command (Standalone.exe -ui) and got:

ERROR: Initialization error - no stackfile to run

Where I would expect - in the console.

Then I created a simple livecodescript file:

  script "foobar"
  on startup
write "foobar" to stderr
  end startup

Then did:

  Standalone.exe -ui foobar.livecodescript

And got 'foobar' in the console I ran it from, and the console did 
nothing more (as standalone engines don't quit unless you explicitly 
close all stacks, or 'quit') until I did Ctrl-C. At which point control 
returned to the console.


So - I think the EditBin suggestion will do as you want - and let you 
create a standalone (built or unbuilt) which runs like a normal console 
command so you should be able to get its output in shell() or from open 
process.


Hope this helps!

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Calling a livecode executable -ui from LC server and get back a result.


On 2017-05-05 18:32, Richard Gaskin via use-livecode wrote:

Thanks for that background, Mark.

Please help me better understand the implications:  does this change
mean that we can no longer run standalones facelessly on Windows by
just calling them with the -ui flag while hideConsoleWindows is true?


No - it changes nothing.

The engine has always been a GUI mode app on Windows - passing -ui just
means it doesn't ever create windows (for all intents and purposes).

The tweak (which was made a long time ago - probably in the 4.x series)
just means that if you happen to launch a standalone from the command
prompt in windows, then if it does write to stdout / stderr, then you
see what is written in the console it was launched from.

It still detaches (as all GUI mode apps do), and won't block the
calling terminal - because that is what GUI mode apps do on Windows.

Unfortunately (as the linked articles mention) it is not possible
to change this behavior after the app is launched - the OS decides
what to do when it is launched by looking at what SUBSYSTEM is marked
in the EXE.

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Calling a livecode executable -ui from LC server and get back a result.

Thanks for that background, Mark.

Please help me better understand the implications: does this change
mean that we can no longer run standalones facelessly on Windows by just
calling them with the -ui flag while hideConsoleWindows is true?

I have a number of apps that provide both GUI and faceless modes, mostly
installers but a few others.

What version did this change premier in?

--
Richard Gaskin
Fourth World Systems

Mark Waddingham wrote:

Hi Malte,

On 2017-05-04 20:34, Malte Brill via use-livecode wrote:

Hi all,

has anybody successfully done this? Especially on Windows? I would
like to launch a livecode built application from a liveCode server
script and get the output back (on a Server that I control) Is that
possible? If so, how?

The problem here is a Windows 'limitation' (well design decision
really).

Windows has two types of executable - console mode and GUI mode.
LiveCode
is a GUI mode application, which means that it detaches from the console
and does not work in the way you would expect when run from the
command-line.

Now, a while I back I added a wee bit of code to the engine to make it
still do something console-y on Windows: on startup it attempts to
'AttachConsole'
which at least means the engine can access the console handles it was
created
with when doing stdout/stderr/stdin type stuff. However, the limitation
here
is that the process is still 'detached' from the parent and so does not
necessarily block open process or shell. (This was done IIRC as a
request
from Roger Eller - I can't remember the exact reasons, but the code
added
seemed to help his specific case, at least).

There's plenty of stuff about this around - Raymend Chen has plenty to
say about it. One notable article being:

https://blogs.msdn.microsoft.com/oldnewthing/20090101-00/?p=19643

Now, one thing he links to from here is:

https://blogs.msdn.microsoft.com/junfeng/2004/02/06/how-to-make-an-application-as-both-gui-and-console-application/

You could try using editbin.exe to change the subsystem type
(editbin.exe is
installed with any of the Visual Studio releases, or tools):

EDITBIN.EXE /SUBSYSTEM:CONSOLE

Then see if this works in the way you want... It might...

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Calling a livecode executable -ui from LC server and get back a result.

Mike Bonner wrote:

> Is there a specific reason you need to use a built exe for this?  lc
> server can use stack files (start using path/to/stack) as well as
> "include"ing or "require"ing extra script files, so unless you're
> using functionality only available in the desktop version of lc, you
> might be able to bypass the need to shell to your exe.  This keeps
> the nice benefit of having instanced runs controlled by a nice solid
> apache server.

My understanding is that LC Server has no event loop, and libURL needs 
that because all of its HTTP handling is done asynchronously (sync 
operations are emulated with an internal flag), which would require an 
event loop to process.

One option might be to write your own replacement for the portions of 
libURL needed, and I started down this road a while back so I could get 
truly synchronous operations.  However, since web servers are 
increasingly using HTTPS, the overhead of handling TLS was more 
time-consuming than I cared to bother with.

If someone else has time on their hands it might be useful to have such 
a lib, but now that tsNet is in v8+ the use cases for it would seem limited.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web

 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Calling a livecode executable -ui from LC server and get back a result.


I think I see the problem here:

Any program that can read from stdin and write to stdout can be used as 
a CGI, and this includes LC standalones...


- BUT -

LC Server scripts are incompatible with LC Script on the desktop.

In fact, it's that incompatibility that made me switch back to using 
standalones for server work many years ago, so it's possible to test and 
debug scripts locally without needing to run them in a server 
configuration and pray that I never need to debug them. ;)


But switching back to what Jacque and I like to think of as "LC Classic 
CGI" means updating scripts that had been written for LC Server's unique 
syntax to be compatible with LC Script as implemented in the desktop.


The upside is that LC Script as implemented in the standalone engine is 
of course fully compatible with the IDE, leading us to just one rule 
that may clarify issues when porting scripts from LC Server:


   If you can run it on your desktop, you can run it on your server.
   And if you can't run in on your desktop, it won't run on your server.

Using the desktop engine facelessly on the server gives us all the 
flexibility we enjoy with LC, which also means we have many ways things 
can be set up to execute.  Too many to write here.


If you have only one script you'll ever need, you can put it in a 
startup handler in the standalone itself.


But I find I use LC standalones so often that I prefer to make a 
standalone that's very slender, containing only enough code to read 
whatever library stack file is specified in the CGI file called, and 
then the standalone runs "start using" with that, and the library 
handles everything from there in a libraryStack handler.


Whether the code is in the standalone itself or in a separate stack 
file, either way you can't use LC Server's "" tags in any 
normal LC Script execution other than in LC Server.


So one way to port your LC Server script below to normal LC Script which 
can be run from the IDE or a standalone would be:



--===--
local sOutputBuffer

on startup
   cgiStart
   DoTheDeed
   cgiEnd
end startup


on cgiStart
   -- Here you load any libs you need, read any CGI environment
   -- variables you might need, etc.:

end cgiStart

on DoTheDeed
   set the shellCommand to "CMD"
   put "" into sOutputBuffer
   put the time  after sOutputBuffer
   put "" after sOutputBuffer
   put Quote & "thes.exe" & Quote &&"-ui" into tShell
   try
  get shell(tShell)
  put "Result:" && the result & cr &"It:" && it after sOutputBuffer
  put "" after sOutputBuffer
  open process tShell for binary read
 read from process tShell until EOF
 put "Result:" && the result & cr &"It:" && it after sOutputBuffer
 put "" after sOutputBuffer
  catch theErr
 put theErr
 end try
 put cr after sOutputBuffer
 put the time after sOutputBuffer
 put "" after sOutputBuffer
end DoTheDeed


on cgiEnd
  put len( sOutputBuffer ) into tLen
  --  Send header:
  put "Content-Type: text/html" & cr &\
 "Date:" && the internet date & cr &\
 "Host:" && $SERVER_NAME & cr &\
 "Content-Length:"&& tLen  into tHeader
  put tHeader
  --  Send body:
  put sOutputBuffer
  -- All done:
  quit
end cgiEnd


Note a couple of key difference between normal LC Script here and the 
specialized form usable only in LC Server:


- Here the "put" command writes immediately to stdout, whereas
  in LC Server it writes to an internal buffer.

- LC Server writes the required HTTP header for us, whereas we need
  to write that ourselves when using the desktop engine.

So as you see above, rather than using naked "put" commands we instead 
put into sOutputBuffer, and then write our header before sending it.


There are other differences as well, such as the enhanced implicit merge 
operation done automatically with LC Server files vs. the need to 
explicitly call the more limited merge function when processing files 
that mix code and HTML.  But since you're not doing that we can leave 
that for another time.


Keep us posted with how it goes.  I use standalones on a wide range of 
systems, including one that needs to exchange data with a client's auth 
server, so I know the sorts of things you want to do are quite 
achievable once you get oriented to moving back to normal LC Script for 
standalones.



Tip: For local development it takes only a couple minutes to create a 
sort of "server emulator", which sets up any environment variables your 
script will be able to get from Apache by just loading them with useful 
values yourself.  In my setup I use a global in lieu of a socket 
connection in my emulator, so I can pass in POST data and get back the 
reply all within the IDE, and with complete debugging capabilities.


--
 Richard Gaskin
 Fourth World Systems


Malte Brill wrote:


has anybody successfully done this? Especially on Windows? I would
like to launch a livecode built application from a liveCode server
script and get the output

Re: Calling a livecode executable -ui from LC server and get back a result.

Hi Malte,

On 2017-05-04 20:34, Malte Brill via use-livecode wrote:

Hi all,

The problem here is a Windows 'limitation' (well design decision
really).

Windows has two types of executable - console mode and GUI mode.
LiveCode

is a GUI mode application, which means that it detaches from the console
and does not work in the way you would expect when run from the
command-line.

is that the process is still 'detached' from the parent and so does not
necessarily block open process or shell. (This was done IIRC as a
request
from Roger Eller - I can't remember the exact reasons, but the code
added

seemed to help his specific case, at least).

There's plenty of stuff about this around - Raymend Chen has plenty to
say about it. One notable article being:

https://blogs.msdn.microsoft.com/oldnewthing/20090101-00/?p=19643

Now, one thing he links to from here is:

https://blogs.msdn.microsoft.com/junfeng/2004/02/06/how-to-make-an-application-as-both-gui-and-console-application/

You could try using editbin.exe to change the subsystem type
(editbin.exe is

installed with any of the Visual Studio releases, or tools):

EDITBIN.EXE /SUBSYSTEM:CONSOLE

Then see if this works in the way you want... It might...

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

Re: Calling a livecode executable -ui from LC server and get back a result.

2017-05-05 Thread Mike Bonner via use-livecode

Is there a specific reason you need to use a built exe for this?  lc server
can use stack files (start using path/to/stack) as well as "include"ing or
"require"ing extra script files, so unless you're using functionality only
available in the desktop version of lc, you might be able to bypass the
need to shell to your exe.  This keeps the nice benefit of having instanced
runs controlled by a nice solid apache server.


On Fri, May 5, 2017 at 6:36 AM, Malte Brill via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Roger,
>
> indeed, I have considdered that. But I have no experience on how this
> would behave. Actually what I was trying to do is reducing the involved
> components, instead of introducing more and more over the course of
> building the system. LC - Server came natural there, as it would have
> allowed me to use liveCode inline and having the proven stability of
> Apache, which is needed for other purposes in the project also. It is so
> unfortunate, that LC-server gets me to 95% of what I need to do and then
> you need to revise your decisions, because some things that you would
> expect to work, just won’t. I can most certainly move everything that is
> needed into a liveCode client, but I would not want to do that because of
> apllication design reasons. Pitty. If I were to set up a faceless app as a
> service / daemon, I am not too sure if I would do it in LC, given that it
> would be a single threaded process and I might need concurrency. The pretty
> part of the CGI approach is that it starts an instance per connection that
> then can act individually. Well, back to whiteboard I guess.
>
> Thanks a lot,
>
> Malte
>
>
>
> > Have you considered running a faceless Desktop app as a service, having
> it watch for a socket message, or a file, or even clipboard content to
> signal it to do something. You could keep an account signed in with an app
> running -with-or-without a UI.
> >
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Calling a livecode executable -ui from LC server and get back a result.

2017-05-05 Thread Alex Tweedly via use-livecode

Could you have the LC Script pass a temp file name to the helper app 
which can then write to that file rather than stdout ? (maybe not really 
a "temp file", but simply a file chosen by the LC Server script based on 
current millisecs time or some such thing, and deleted after everything 
is finished.)


And the LC Server script can simply wait until the helper is done, and 
then read the file (and then delete it).


Alex.


On 04/05/2017 19:34, Malte Brill via use-livecode wrote:

Hi all,

has anybody successfully done this? Especially on Windows? I would like to 
launch a livecode built application from a liveCode server script and get the 
output back (on a Server that I control) Is that possible? If so, how?

I tried a couple of things to no avail:

"
   put the time
   put ""
   put Quote & "thes.exe" & Quote &&"-ui" into tShell
   try
 get shell(tShell)
 put "Result:" && the result & cr &"It:" && it
 put ""
 open process tShell for binary read
read from process tShell until EOF
put "Result:" && the result & cr &"It:" && it
put ""
   catch theErr
   put theErr
end try
put cr
put the time
put ""
?>

the helper app: In the stack script:

on startup
   send "boo" to me in 500 millisecs
   — to make sure all libs are loaded
end startup

on boo
   quit
end boo

on shutdown
   write "boo" to stdout
end shutdown

Thanks for all input I can get…

Malte


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: Calling a livecode executable -ui from LC server and get back a result.

2017-05-05 Thread Ralph DiMola via use-livecode

I am running my Android Remote Tester LC app as a Windows Service on Win 10. It 
has a UI for debugging/examining operation when run in the Windows UI and this 
UI does not cause any problems when running as a service. I just startup up 
everything in the preopenstack. This app does socket communications for user 
requests and performs various functions including shelling out to the OS and 
returning the result back to the client. It's been very reliable while running 
as a service and has never has any mysterious crashes. This app supports multi 
user connections. I use the socket address as an index into an array for 
session context. As it is single threaded, it has to finish one request before 
it can work on the next but does not have the overhead of starting up a new 
process for each connection/request. Could this work for you?

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Malte Brill via use-livecode
Sent: Friday, May 05, 2017 8:36 AM
To: use-livecode@lists.runrev.com
Cc: Malte Brill
Subject: Re: Calling a livecode executable -ui from LC server and get back a 
result. 

Hi Roger,

indeed, I have considdered that. But I have no experience on how this would 
behave. Actually what I was trying to do is reducing the involved components, 
instead of introducing more and more over the course of building the system. LC 
- Server came natural there, as it would have allowed me to use liveCode inline 
and having the proven stability of Apache, which is needed for other purposes 
in the project also. It is so unfortunate, that LC-server gets me to 95% of 
what I need to do and then you need to revise your decisions, because some 
things that you would expect to work, just won’t. I can most certainly move 
everything that is needed into a liveCode client, but I would not want to do 
that because of apllication design reasons. Pitty. If I were to set up a 
faceless app as a service / daemon, I am not too sure if I would do it in LC, 
given that it would be a single threaded process and I might need concurrency. 
The pretty part of the CGI approach is that it starts an instance per 
connection that then can act individually. Well, back to whiteboard I guess.

Thanks a lot,

Malte



> Have you considered running a faceless Desktop app as a service, having it 
> watch for a socket message, or a file, or even clipboard content to signal it 
> to do something. You could keep an account signed in with an app running 
> -with-or-without a UI. 
> 

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Calling a livecode executable -ui from LC server and get back a result.

Hi Roger,

indeed, I have considdered that. But I have no experience on how this would 
behave. Actually what I was trying to do is reducing the involved components, 
instead of introducing more and more over the course of building the system. LC 
- Server came natural there, as it would have allowed me to use liveCode inline 
and having the proven stability of Apache, which is needed for other purposes 
in the project also. It is so unfortunate, that LC-server gets me to 95% of 
what I need to do and then you need to revise your decisions, because some 
things that you would expect to work, just won’t. I can most certainly move 
everything that is needed into a liveCode client, but I would not want to do 
that because of apllication design reasons. Pitty. If I were to set up a 
faceless app as a service / daemon, I am not too sure if I would do it in LC, 
given that it would be a single threaded process and I might need concurrency. 
The pretty part of the CGI approach is that it starts an instance per 
connection that then can act individually. Well, back to whiteboard I guess.

Thanks a lot,

Malte



> Have you considered running a faceless Desktop app as a service, having it 
> watch for a socket message, or a file, or even clipboard content to signal it 
> to do something. You could keep an account signed in with an app running 
> -with-or-without a UI. 
> 

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Calling a livecode executable -ui from LC server and get back a result.

2017-05-05 Thread Roger Eller via use-livecode

Have you considered running a faceless Desktop app as a service, having it
watch for a socket message, or a file, or even clipboard content to signal
it to do something.  You could keep an account signed in with an app
running -with-or-without a UI.

~Roger

On Fri, May 5, 2017 at 6:48 AM, Malte Brill via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Thanks Dan, but that is not what I am after…
>
> I have a server side liveCode application, which needs to talk to a couple
> of webservices from time to time. While this works nicely on the desktop,
> it does not do so on Server, as Server lacks some libURL functionality.
> First workaround was to shell out to cURL. This works nicely on Mac and
> Linux servers, but forever reason fails under Windows Server, which I need
> to support. So the next thought was to call a liveCode executable -ui when
> needed, but I do not get a result back there. I will not want to have a
> liveCode standalone running 24/7 on a server machine. I guess the easiest
> way out is to simply kill off the idea to treat liveCode server as a
> replacement for PHP and just bite the bullet and build everything in PHP
> instead. Or start an initiative to get libURL ported to server. I already
> talked to the guys in Scottland to see if this would be feasible, but it
> would cost a bit more than I could afford alone. I might just go with
> having the single command implemented I would need for the project
> (libURLLastRHHeaders), which then would also lift the requirements for
> having to use cURL or any other helper app in my case, but I am not quite
> sure if that makes sense…
>
> Would anybody else like to see libURL feature parity between Desktop and
> Server engines and if so be willing to set up a fundraiser with me for this?
>
> Cheers,
>
> Malte
>
> > You can communicate between server and desktop using sockets. Chatrev is
> a
> > good example of this
> > http://www.bjoernke.com/index.irev?target=chatrev
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Calling a livecode executable -ui from LC server and get back a result.

Hi Charles,

thanks a lot for the information. I am afraid I can not use it in this context, 
as this is for an Open Source project. For other things this might be an option.

Cheers,

Malte

> Hi Malte,
> 
> If you are able to use the commercial version of LC server, the tsNet 
> external is supported which provides equivalent functionality to libUrl.
> 
> Regards,
> 
> Charles
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Calling a livecode executable -ui from LC server and get back a result.

2017-05-05 Thread Charles Warwick via use-livecode


Hi Malte,

If you are able to use the commercial version of LC server, the tsNet 
external is supported which provides equivalent functionality to libUrl.


Regards,

Charles


On 5/05/2017 8:48 PM, Malte Brill via use-livecode wrote:

Thanks Dan, but that is not what I am after…

I have a server side liveCode application, which needs to talk to a couple of 
webservices from time to time. While this works nicely on the desktop, it does 
not do so on Server, as Server lacks some libURL functionality. First 
workaround was to shell out to cURL. This works nicely on Mac and Linux 
servers, but forever reason fails under Windows Server, which I need to 
support. So the next thought was to call a liveCode executable -ui when needed, 
but I do not get a result back there. I will not want to have a liveCode 
standalone running 24/7 on a server machine. I guess the easiest way out is to 
simply kill off the idea to treat liveCode server as a replacement for PHP and 
just bite the bullet and build everything in PHP instead. Or start an 
initiative to get libURL ported to server. I already talked to the guys in 
Scottland to see if this would be feasible, but it would cost a bit more than I 
could afford alone. I might just go with having the single command implemented 
I would need for the project (libURLLastRHHeaders), which then would also lift 
the requirements for having to use cURL or any other helper app in my case, but 
I am not quite sure if that makes sense…

Would anybody else like to see libURL feature parity between Desktop and Server 
engines and if so be willing to set up a fundraiser with me for this?

Cheers,

Malte


You can communicate between server and desktop using sockets. Chatrev is a
good example of this
http://www.bjoernke.com/index.irev?target=chatrev


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: Calling a livecode executable -ui from LC server and get back a result.