Joe, (et al)

Yes. I sort of follow your example. Btw, I perhaps used the word stack when
I should have said queue, because I believe a queue is first-in-first-out,
which is what I want.

So, I imagine the command event at the jhs side sending a command and the
jhs responding by emptying the queue and then executing the command as if
it is a valid j command, which hopefully it is.

Each time that command triggers the j verb  paint it will add all 13 arrays
needed for a single draw() to the queue, and after the last visit to paint
a jhrajax will send the queue's contents to the js/webgl side which will
use the .length of the queue array to know how many times to update the
canvas as a simulation.

The big question is, how does J know that the last paint operation has been
completed? For example, is there some way to detect an idle status in J? I
seem to recall something like sysevent that could do that. No luck with
this search:

site:jsoftware.com sysevent

So I guess your "Client" is my JS, and your "Server" is my J. Right?
But I don't know how to tell when Server is finished thinking.

On Sat, Mar 22, 2014 at 4:13 PM, Joe Bogner <[email protected]> wrote:

> On Sat, Mar 22, 2014 at 2:06 PM, Brian Schott <[email protected]>
> wrote:
> > Actually I guess J could
> > assume all commands are multiple commands and then save up the multiple
> > results in a stack to finally be sent to JS.
>
> This is the only option I can think of too.  Let me restate the
> problem in more general terms:
>
> User wishes to interactively use Client to send commands to Server.
> Client should collect results of each invocation and do something with
> them.
>
> 1. Client sends command to Server
> 2. Server interprets command and sends back result(s)
> 3. Client appends results to any previous results and operates on the
> collected list
>
> One possible implementation, aside from Turtles, would be to create an
> app that lets a User input a number and returns the list of factors
> for the number. The app could show the frequency of factors for all
> the numbers that have been input.
>
> Number: 13
> Factors: [1,13]
>
> Number: 4
> Factors: [[2,2],[4,1]]
>
> The app would show
>
> 1: 2
> 2: 1
> 4: 1
>
> Anyhow, it would need to be able to operate on a situation of multiple
> results. So, I recommend the Server always return an array of results.
>
> So, the first case would be [[1,13]]
>
> Hope this helps
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>



-- 
(B=)
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to