On 4/25/06, Jörg F. Wittenberger <[EMAIL PROTECTED]> 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). _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
