Re: OT: Re: [Chicken-users] rails-like framework

[Shawn Rutledge]

On 4/25/06, Jörg F. Wittenberger <address@hidden> wrote:
> Am Montag, den 24.04.2006, 15:12 -0700 schrieb Shawn Rutledge:
> > Well I see the idea of calling a web framework an OS is not new:
> >
> > http://blogs.zdnet.com/web2explorer/?p=166
>
> So who was the first one? ;-)

Oh you guys started the trend?

> There's quite a lot on my wish list.  But there I distinguish between
> application level, where your Scripts and libraries reside, and kernel
> level, which just does the message routing and state synchronization.

In which level are the model objects then?

> Unfortunately the security experts insist for a reason, that you can't
> build security into an insecure system, it has to be build in right from
> the beginning.

Yeah and the other risk is if you worry about too many things at once,
the prototype never gets done.  The Xanadu project to me is both a
great inspiration, and a great example of how not to get anything
done.  I would like to have all of its features and then some, but not
to get trapped in 40 years of tailspin.  Anyway to me security is the
least interesting part of the problem, and I'm not an expert.  I
thought the Eros project sounded very interesting, mostly because of
the orthogonal persistence implementation.  But the focus is the
capability security model, which is also interesting but probably
that's the only thing that will be accomplished, the way the project
is going now.  What do you think of that?  Seems to me it could work
pretty well in a system like this.

> And that's more true, when the focus is legal processes.  This *must* go
> down to the system architecture or you'll loose all your development
> work eventually.

Are you saying this about all possible software projects or just Askemos?

I don't know if a few humans can design a system so tamperproof as to
keep out the billions of other humans trying to tamper with it.  It's
worth a try but I think security will have to keep evolving as
different methods get cracked.  The best methods that have been
envisioned don't even exist yet (like quantum computing).  We'll see
if existing security architectures will adapt well to those new
methods over time.

> The good news is, that we have it usable.  Our pages look slightly
> simpler that plain Spiffy or this ajax frame work posted these days.
> Well, to me and I'm biased.  But I know about at least one person, who
> just picked Askemos/BALL because of it's mix of XML transformation
> features ignoring all the sec. features.

XML transformation is yucky and inefficient IMO.  My least favorite
language of all is XSLT.

> Yes and no.   No, you don't want to trust any binary only data format.
> Especially not, when it's a gziped memory dump.  Furthermore there are

Wow it's even worse than I thought.

What about hooking Scheme to a more stable, portable sort of OODB?

Another idea I had is if Scheme people could agree on an ideal VM
implementation (like Java or C# has), and an efficient portable binary
data format, then binary transport (like RMI in Java) and binary
serialization to files would be more trustworthy.  But when VMs are
developed, not a lot of bragging is done about the design of them.  I
studied QScheme a bit; it has one.  Kali seems to be one of the most
complete distributed Schemes (even continuations can travel from one
machine to another, and be executed there) so doesn't that imply that
it has a portable bytecode and portable data structures?  But if you
design such bytecode and data structures for conventional 32-bit or
64-bit machines, it will not be optimized for an ideal Lisp machine
(the kind that has extra bits to store the data type) and you have to
do tricks like limiting ints to 29 bits (Chez does this).  And we
happen to be in a transition from 32-bit to 64-bit computing, so if
you allow 64-bit addresses for upwards scalabilty, the bytecode is not
as portable to, say, embedded devices or small platforms.

As for Chicken, is there a VM?  I'm guessing not, because for speed
you just use the compiler, and therefore not a lot of emphasis would
be placed on making the interpreter the fastest.

What does RScheme do?

> >  These are the reasons I think maybe a human-readable S-expression
> > form is good for persistence.
>
> Hm, XML has a few more editors and I'd expect them to become usable
> eventually.  I don't think this will be the case for S-expressions any
> time soon.  (Well, up to emacs etc. editing help, that's not the type I
> think of.)

IMO somebody needs to write a better editor for S-expressions.  Good
XML editors are also nontrivial.

XML is such a fad, but it is far from optimal for either machines or humans.

At work I came up with a binary format that is portable, and allows
you to store the same kind of structures as you would express in XML
(trees of name-value pairs), but is very compact, and safe for binary
data (an int is really stored as an int - not a string, and there is a
BLOB type as well).  I feel that I could trust it because the bytes
are in network byte order, and I know the format of the file.  (It is
not resilient to data corruption, though.  One flipped bit in the
wrong place can lead the reader off into the weeds.)  The design is
straightforward and obvious (yet, other designs like WBXML are very
similar but have flaws which I think I got around in this design.  I
was surprised it has not been done quite this way before.)  There is a
string table at the beginning for tags and for enumerated values; each
tag uses the string table index so this is much like Scheme symbols -
the ASCII string only exists once.  Each tag has a length (so you
don't need a delimiter to end the "value" part of the tag).  The
length includes that of the child tags, so you can skip over entire
subtrees at read time if you decide that they are not interesting - no
need to parse every byte as with ASCII formats.  Bool tags are
particularly efficient; I can store a tag and its boolean value in 2
bytes.  I don't know if they would let me open-source the
implementation (not likely) but I did this in both C++ and Java and we
have used it successfully on multiple platforms and processors.

I could do something similar for S-expressions (same idea, but more
datatypes).  One core problem I think for distributed Scheme is how to
negotiate a shared symbol table, to try to eliminate a level of
indirection (multiple machines could end up using the same numeric
value, or pointer, for each symbol that is known to all the machines).
 The same thing applies to persisted binary files - let's not repeat
symbol tables any more often than necessary, or even if we do put the
symbol table in every file, the unification process must occur when
the file is loaded, so that in memory you don't need multiple contexts
with their own symbol tables.  This is a low-level detail which can be
procrastinated, and I'm not quite sure how to do it the most efficient
way.  (Maybe MMU tricks could be used effectively.)  So in the
meantime ASCII S-expression files (or a binary equivalent, with the
relevant symbol table fragments repeated in every file) are nice and
portable, yet not as verbose as XML; and the assumption would be that
humans don't write them - they use friendly tools.  Nowadays many
people don't write HTML by hand, and eventually I think nobody will be
writing XML by hand either.  But there is no insanely great XML editor
yet, is there?  Nor is there for Scheme, unless you count Emacs (which
I have still not learned to use).