PortaCello3 Update [was Re: [cello-devel] scroller]

[Kenny Tilton]

Frank Goenninger wrote:

>How about a communicating cells super-structure. One cells instance
>running on one system and the other on another system. Then have
>instances of cells move between those two systems.
>
The /cells/ move?

> This then is dataflow
>beyond machine boundaries!
>
Actually, that has already happened, in the CliniSys app. Two 
applications on different machines were both accessing a multi-user 
networked database. After any write operation, applications broadcast 
the news via IPC so any other running app could look at the I/O and then 
check internal tables developed for this purpose which kep track of 
cells that "cared about" the I/O in one of several ways.

The effect was that one could be looking at "Patient Page 12" on machine 
A and see it change when some changed the same page on Machine B.

Without a DB we just need a way for a rule for a slot for an instance of 
an application on machine "A" to /reference/ the slot of an instance of 
an application on Machine B. So you just need to work out a network 
"namespace": \machine\processname\... and now you are into the Cello 
namespace. A reasonable amount of socket glue and away you go.

This could be a cool way of doing tech support, where one would "take 
over" the users application to get the settings right, or at least tie 
in to see what the user was doing to better help them (tho I know win32 
at least offer OS-level tricks to do the same).


>
>And if the transported cell contains some code fragment that will be
>evaluated on the other system but knows it came from the other system
>would mean to have transparent cell communication between machines.
>
I still do not see moving Cells, I see cross-network slot-references and 
/data/ moving.

>
>Another thought: make synapses work as connection streams between
>machines and just allow connects between systems with that mechanism.
>
Synapses are instantiated between two Cells once the using (calculating) 
cell has found the used cell. So we still need the (straightforward) 
setup described above to get to that point, and then Synapses just do 
what they do now. But you are right, every cell dependency is a stream. 
Maybe I should use that word with some audiences instead of spreadsheet 
or dataflow.

So would that be an insanely great demo, say having the light panel 
spinning shape on one machine and the controls on another, with only 
generic socket/cell code in between? Mind you, it does not get to the 
issue of apllication complexity, but if a transparent  network IPC trick 
gets people interested, maybe that is the way to go.

It would be cool if the second laptop were running SBCL/OSX or 
something. Diff OS /and/ Lisp implementation would be key. Have you 
considered downloading the Lispworks freebie for Linux to see if your 
port Just Works?

Getting back to streams/synapses, I was starting to reconsider. Synapses 
could make things more efficient in a couple of ways, and they should 
sit on the sending (used) side so, if they decide not to fire, that gets 
done as quickly as possible (if the synapse sits on the receiving side 
an unnecessary roundtrip is made). Of course, the synapses we are 
conceiving would always fire (the other kind of synapse is pretty rare, 
and we are just using synapses to make the network faster). The other 
thing is that now I have to hardcode the using application to include 
synapse factories on all the slot references.

So it is probably better to borrow the synaptic concept and do it as an 
internal cells engine trick when it sees a networked reference, or more 
generally, an interprocess reference--anytime the namespace search goes 
outside the user process. So the developer does not worry about it, they 
just make sure they get the URL, if you will, right. Conceivably we take 
it further and let something like:

     :layers (c? (list (rgba-value (fm-other :hedron-colorizer)) :fill))

..and let the model search for a widget named :hedron-colorizer go 
outside the process to the network, so it gets decided at runtime.

But I think this special synapse should actually be a subclss of 
synapse, because some of the functionality I have in mind for it is 
stuff I considered for regular application-level synapses. Such as the 
idea that a synapse can actually set the new value for a using cell, 
short-cutting the propagation even for local cells. In the case of the 
network, this would be huge: instead of just telling the remote cell to 
recalculate, requiring another trip to come get the value when the rule 
gets kicked off, the used cell just provides the using cell with its new 
value.

This works whenver  a rule can be supplied to the used cell for how to 
calculate the using cell given only the new value of the used cell. So 
if the rule is:

    :slot-c (+ (^a)(^b))

it is easy: (incf <using value> (- new-a old-a)). In fact, a code-walker 
could work this out.

And in developing the application we can, without hardcoding for a 
network, at least keep in mind that references to other widgets which 
might be anywhere should be kept in simple rules for which an inverse 
relation can be expressed. ie, don't embed a reference to a widget in a 
30-line rule, or a rule which hits 3 other widgets. Break those out 
artificially into intermediate references. ie, keep heavy-lifting local 
to the client.

Is anyone asking for this? I missed the whole age of networked systems, 
so I do not know.

kt



-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application