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

[Frank Goenninger]

On Mon, 2004-04-12 at 08:30, Thomas F. Burdick wrote:
> Kenny Tilton writes:
>  > 
>  > 
>  > 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?
>  > 
Well, it was just a bit aside from full truth - but makes for a great
marketing phrase

"Cells moving between bodies - Scotty beams them from machine to
machine!" <g>

>  > > 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.
>  > 
And we are back again to our Model-View-Controller model long known but
having to be re-invented for those kids growing up nowadays.

>  > 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.
>  > 

As for the identification of individual instances or slots or anything
else I'd suggest looking for URI and RDF as the way to go instead of
using plain URLs or even inventing a new resource identification method.

>  > 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).

Yes, there are low-level OS tricks. But why use OS specific things when
you can have a portable solution ?

> 
> This is really tangential, but what tricks are those?  I'm curious
> mainly to see if there's something similar on Unix/Mac, since I do
> deliver end-user apps sometimes.
> 
Well, as long as it is X11, you can always "tap in" into the streams
used in X11 to transmit display data. Have done it once in just that
type of app: supporting a remote user from a central place.
Already 12 years ago now... So don't ask me about real function
names - it was pretty low level X11 stuff.

>  > >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.

Yeah, right - it's not cells actually /moving/ between machines. But:
If they actually do in a hypothetic solution what would that be good
for?
I'm just trying to think the unthinkable. Mobile Agents? Mobile Cells?
What would be possible applications? 

Coming to my mind:
- Distributed knowledge representation
- Fault tolerant systems
- High-availability on application level: mirroring Cells
- Load balancing / load optimization
- Self-organization based apps

Am I going crazy now? ;-) 

> 
> This seems the right way to do it to me, too.
> 
>  > 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.
> 
> Yeah, and if the developer whats something else, they can build their
> own out of the blocks that network-transparent cells were built out
> of: cells, sockets, and synapses.
> 
>  > Is anyone asking for this? I missed the whole age of networked systems, 
>  > so I do not know.
> 
> No, of course not, for the same reason no one's asking for CL :-).  If
> you ask me, what you're talking about is the natural application of
> Cells to networked systems, so to the extent that anyone's asking for
> Cells/CL, they're asking for this.  The model (no pun intended) needs
> authentication and authorization layers ("who are you?" "can you do
> what you're trying to?").  You can always build such on top, but the
> same applies to CMUCL's WIRE package, which is underutilized for just
> that reason.

These are very important points: authentication and authorization need
to be fully integrated into cells if we go networked. 

I would not build them into cells but as a separate layer using hooks
in the "right" places within cells. So anyone wishing to use another
model could do so easily.

And yes, having those things ready to use for such a pervasive app
foundation like Cells will boost the overall acceptance and usage 
of Cells.
 
73 (amateur radio code for: best regards)
  Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cello-devel/attachments/20040412/a416f85e/attachment.sig>