Planning ahead for threads and more interactivity in rev apps

[Phil Davis]

Hi Xavier,

One approach is to have a primary app which offloads 'blocking' or 
time-consuming tasks to invisible secondary apps (also built with Rev) 
via sockets. So the primary app would open a connection, tell the 
secondary app what to do, and close the connection (or use a datagram). 
Then PrimaryApp is free for other tasks while SecondaryApp does the 
lookup. When SecondaryApp has some results, it opens a socket to 
PrimaryApp and writes the results to it (or tells PrimaryApp about a new 
data file containing the results, or...)

The use of socket communication keeps interactions message-based or 
event-driven, which will keep PrimaryApp focused on managing server info 
results rather than obtaining them. I believe that's what you want.

This approach is somewhat scalable too; you can have several invisible 
SecondaryApps running if needed. (But that does add complexity to task 
management)

Anyway, food for thought...

Phil Davis


xavier.bury at clearstream.com wrote:
> Hi everyone,
>
> In order to make an application more responsive, im thinking of 
> implementing a kind of threading so that the application can still run 
> while the GUI remains responsive. The application in question is a domain 
> scanner and it scans some hundreds of servers which takes quite a while 
> given the number of servers, their locations or type (phys. or virtual). I 
> dont need this to go faster mind you but i dont want to go slower 
> either... 
>
> All i need is to be able to browse tabs and eventually change a setting or 
> another.
>
> Problem is that mouse interception is not really working because of the 
> intermittent shell calls and any mouseclick seems to get lost. Unless i 
> want to click for 1-4 minutes and wait with the mousedown which i dont 
> really fancy for anyone to suffer.
>
> Using "send" is also not a good idea because i use shell commands that may 
> take different times to finish - some servers are vmware slow or are 
> located in places like dubai or Prague may not respond too quickly... 
> Problem with the send command is that if you ask it to send something in 5 
> seconds and there is a process already running, the send will definitely 
> not run in 5 seconds... And worse, it may prevent intercepting your 
> mouseclick.
>
> I was thinking of a script that runs the shell, waits if mouseclick or 
> something like that... But last thing i want is to make this complex code 
> more complex... And im not sure the mouseclick will not be lost while the 
> script runs. 
>
> Something "interactive" is what I am looking for...
>
> Last but not least, i can't (or dont want to) manage more than 1 shell 
> running at a time using a quick batch runner - meaning i'll have to manage 
> interleaving and limiting processing load. The server has other functions 
> and i can't monopolize the processors... Although this seems like my best 
> solution.
>
> Im just planning ahead this feature so all your ideas are welcome! Im sure 
> many of us revvers are looking for a script like this at some point for 
> applications that take time to process... 
>
> Thanks in advance
> Xavier
>
>
> ----------------------------------------------------------------------------
> Clearstream Services S.A.
> 42 Avenue JF Kennedy, L-1855 Luxembourg
> Société anonyme is organised with limited liability
> in the Grand Duchy of Luxembourg R.C.S. Luxembourg B 60911.
>
>
> -----------------------------------------
> Visit us at http://www.clearstream.com
>
> IMPORTANT MESSAGE
>
> Internet communications are not secure and therefore Clearstream
> International does not accept legal responsibility for the contents
> of this message.
>
> The information contained in this e-mail is confidential and may be
> legally privileged. It is intended solely for the addressee. If you
> are not the intended recipient, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance
> on it, is prohibited and may be unlawful. Any views expressed in
> this e-mail are those of the individual sender, except where the
> sender specifically states them to be the views of Clearstream
> International or of any of its affiliates or subsidiaries.
>
> Legally required information for business correspondence/
> Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz:
> http://deutsche-boerse.com/letterhead
>
> END OF DISCLAIMER
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>