Re: what to do w/ hosts

 > From: Harlan Stenn <[email protected]>
 >
 > IMHO one needs both "push" and "pull".

    Agreed.

 > From: Will Partain <[email protected]>
 >
 > is effectively 'pull'.  That is, at the "engine level", you
 > can be either push or pull; we don't legislate (and my
 > instinct is *not* to).

    Yes, but note the amount of code you have to implement to paper
over the distinction.  I think you can get there differently than
trying to shoe-horn the different issues push vs pull have in to one
place.

 > I wonder what an ARK world would look like if we made
 > "push"-style operation simply impossible/inexpressible?  How
 > would we do something like Jonathan's routers, or a
 > not-a-proper-computer NetApp filer?

    One way of implementing this would be to outfit a seperate control
infrastructure for push concepts.  There are reasons to do this -- the
model for push is distributed, whereas pulls probably happen from a
single conceptual point.  I think it helps to think of them as
completely different things for security and risk management.  I
personally don't want to be doing remote code execution through both
of these paths -- I would rather the pull infrastructure lay down what
you can specify through the push infrastructure.  Not pushing code
through control also enables better auditing, as long as you planned
for the operation ahead of time (once you have to login, all bets are
off).

 >    ark router tip-me-over-gently ALL
 >
 > (This is kinda the opposite of "pull"-only -- it's "I don't
 > want to ever run ARK stuff directly on this box, ever".)

    So in my way of thinking, this would translate to a command that
evaluates the object model locally, and performs the work either
directly from where you're doing the push, or asks through the control
system that the responsible machine(s) (located through the object
model) do it.

    I've got some of this stuff implemented in a half baked local
infrastructure, but a lot of what I'm talking about here is mostly
conceptual stuff that's less than half implemented.