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

[F. Wittenberger]

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? ;-)

> Somebody states the obvious, that DHTML + Javascript isn't very nice
> and wouldn't it be great if we could start over.  I've been thinking
> for a while that Scheme could be the universal language for such
> things - you could describe the page and write the scripting to make
> it dynamic, and write the server-side code, in the same language. 
> Hopefully by using higher-level abstractions that gloss over the fact
> that it's a distributed application.  This is what I ultimately want
> to accomplish.  I want the same app to run on a single machine, or as
> a web app on a legacy browser, or on a new kind of browser that is all
> Scheme, without having to rewrite the app.  So are these the kinds of
> goals you have in Askemos too?

Yep.  I expect Askemos to cater the "M+C" part of the MVC.  Run the app
(business logic) regardless of the choosen viewer.

And run the backup too.  In case my machine blows up is is beeing
rooted.

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.

>   It doesn't seem well-defined enough,
> and more concerned with being secure and tamper-proof, whereas I would
> be glad to achieve usefulness first, and worry about security later.

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.

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.

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.

However: we lack ajax right now.  It's pretty much in focus, but not
there yet.

> 
> A side project is how to get rid of the parentheses so that ordinary
> people can tolerate writing Scheme.  :-)  I think it's just a matter
> of writing a really awesome editor that understands a lot of common
> constructs and displays them appropriately.  It should look something
> like MathCAD but have graphical representations for every concept used
> in programming, not just math expressions.   You would edit the lists
> in memory directly, and the textual syntax is only the output when you
> save it to a file.
> 
> Rscheme sounds interesting in that it has object persistence already. 
> Can you trust it?  Can you be sure that data will not be lost to
> obscurity because it's in some platform-specific binary form?  Can you
> trust it not to change in incompatible ways so that your data is lost?

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
size limits.  But it helps to reduce load time.  So I'm caching a lot of
intermediate data.  But there's always a "canonical" copy in, well,
that's why I decided to go XML.


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

>   And leverage the filesystem to do some
> of the indexing work (e.g. use a lot of files rather than one big
> file, laid out into a tree that makes sense.  Just in case the code
> has to be re-written some day.)

That's how I keep the "canonical" form.

> Otherwise there are some other object databases that are not
> Scheme-specific (Goods, and the Zope one for example).
> 
> On 4/22/06, Jörg F. Wittenberger <address@hidden> wrote:
> > Dear all,
> >
> > who are interested in a decent web programming framework in Scheme.
> >
> > We've been spending quite a while on such a thing and I'm simply not the
> > person to brag about my part of work (which has been too much), maybe
> > that's the reason it makes me sad  watching you people here calling for
> > it in *chicken*.  That makes my posting off topic.  But I can't resist,
> > since you really don't know what you are missing right next door:
> >
> > There's a web programming framework in rscheme.  I've been close to a
> > chicken port once.  And I'm longing for it, since I hope we could
> > eventually leverage the larger user base to fasten development instead
> > of working almost like proprietary developers, though we've been open
> > source from the very beginning.  (To be fair: for the initial
> > development, a bazar style would not have been helpful, so we did not
> > try.)
> >
> > Our framework appears to the Scheme programmer in a way like two Scheme
> > alike programming languages.  One just as any Scheme, think of your
> > favourite Scheme interpreter and one, which is like a coarse grained
> > Scheme.  (But it's not [yet] a complete Scheme.  The vm kernel
> > implements only basic operations.  Enough to build a Scheme interpreter,
> > which is left to be done.)  This coarse grained virtual machine is
> > intended to keep persistent application state.  It supports a the actor
> > programming model, whereby each object/actor is merely just a
> > continuation.  Those talk to each other using asynchronous messages.
> > Much like Erlang or E ( http://www.erights.org/elang/index.html ).  The
> > MVC model is deeply build in the system too.  For two reasons: for one
> > thing it's a difference from a legal point of view, whether you explore
> > things without modification or if you apply methods, which may cause
> > modifications.  Second: optimisation: for idempotent operations, we
> > don't need to take locks.  Therefore our "view" parts are written in a
> > Scheme subset, which can not mutate persistent data (subsets of Scheme,
> > XSLT and SQL).  (BTW: a [fixed] SRFI 49 can be useful, for SXML. ;-)
> >
> > Still missing is some ajax support.  Shouldn't be too hard.  Want to see
> > the classic address book example (w/o SQL)?
> > http://askemos2.tc-mw.de/A67bb0753e1676f81983e0ecf3a15b391/UsingWeightBalancedTrees
> > (scroll down to "Source code:")
> >
> > But Askemos is defined as a protocol (not an implementation), keeping
> > such coarse grained Interpreters synchronous in byzantine agreement.
> > This means: a certain minority of hosts can get lost (due to disk crash,
> > malicious hackers, unreliable administration, gun power or whatever
> > disaster), your applications continue to run untroubled.  If you where
> > to run on a few hosts together with your, say business partners or
> > friends, connected over tor (tor.eff.org), you where safe even against
> > physical extortion.  Just let them take the machine, where you kept your
> > encrypted notes and ask your partners for their copy.  If we had
> > multiple implementations, it would be even better: if one implementation
> > broke (say a bug would let you take over any program written in a
> > particular Scheme implementation), the heterogeneous net is uneffected.
> >
> > The fact that we need such a protocol eventually (to evade the chaos of
> > computers taken out of control and random due to broken DRM systems)
> > made me define the VM in XML.  That's what I call coarse grained: all
> > persistent data has an XML representation (besides the internal
> > structure, which we cache too).  And a checksum is taken for each and
> > every transaction and agreed upon over the net.  This is kind of slow
> > (think of 0.3 seconds per mouse click over WAN/SSL and a few seconds
> > when using tor [pipelining will help one day]) and that's why there are
> > two interpreters: the "traditional" one for the computation itself and
> > the byzantine to update persistent state which may not get lost or
> > tampered with.
> >
> > On the wire you get to speak http/s, WebDAV and lmtp/smtp out of the
> > box.  So your applications will typically talk SOAP or alike to the
> > outside world.  But that's app developer's decision.
> >
> > The main intent was to allow to model legal systems.  Legal purposes
> > require to record some meta data with all values.  You must always be
> > able to verify the author, timestamp of creation, determine that
> > document are unmodified and determine the local interpreter (needed for
> > tamper proofed processes, would go far beyond this posting).  Ensuring
> > correctness using a Askemos network goes far beyond the simple
> > guaranties associated with timestamps from accredited and certified
> > providers.
> >
> > The most interesting thing is of the whole framework is the capability
> > system.  Since we are not interested in a toy system, it has to make
> > sure that no player will be able to intrude the system.  Even at initial
> > setup.  All byzantine agreement was useless, if one you partners is in
> > your reliance set for logical reasons.  Therefore users (and the public)
> > are like citizens of the network and the root of their private
> > capability hierarchies.  They are equal among each other.  No other
> > pre-system start capability distribution exists (like in E).  No super
> > user to hack.  (AFAIK Askemos is still the only system, which can proof
> > this "incorruptible" property, which is essential for accountability.)
> >
> > Find it working at www.askemos.org , askemos1.tzv.de and
> > askemos2.tc-mw.de . Those 96.2982% write availability seen here
> > http://askemos2.tc-mw.de/A539cdd39291e7d159c68bb199f5a88d5
> > include downtime due to kernel development, network partinioning etc.
> > (and in theory, three machines is already like 1/4 missing).
> >
> > Think of it.  Askemos gives you a degree of certainty and reliability
> > not yet found anywhere else.
> >
> > Just it's not yet available in chicken.  If you where to start again,
> > please consider to join and help to port it over to you favorite
> > language.
> >
> > Am Samstag, den 22.04.2006, 13:13 +0200 schrieb Peter Bex:
> > > On Fri, Apr 21, 2006 at 02:05:45PM -0700, Brandon J. Van Every wrote:
> > > >    I'm  afraid  my  own Chicken projects are getting the backburner 
> > > > right
> > > >    now.  Technical stuff is just too much work when I'm spending a lot 
> > > > of
> > > >    time  signature  gathering.   The  season  ends in early July and if 
> > > > I
> > > >    don't  travel  to  another  state to do more work, then I'll have 
> > > > more
> > > >    time  for  Chicken.   This  kind  of  problem  of  critical  mass, 
> > > > and
> > > >    application interest, is why Ruby has Rails and Chicken doesn't.
> > >
> > > If I recall correctly, Rails was initially done by one person/small team
> > > for a website.  Later the Rails stuff got separated from the project.
> > >
> > > In essence, Rails isn't that much: it's a handy hack for building class
> > > layouts from a database table description (ActiveRecord), some addon
> > > libraries for the Time class and a framework that aids in implementing
> > > the model/view/controller (data manipulation/presentation/logic)
> > > separation.  It also includes some stuff to do Ajax, but we already
> > > have that in the Ajax egg.  And some session support, but we can do
> > > that easily, and even _better_ with continuations.  See
> > > (http://radio.weblogs.com/0102385/2004/04/03.html#a568) for some tasty
> > > stuff.  This could ideally be integrated in Spiffy.
> > >
> > > I think the hardest thing will be the ActiveRecord-like support since
> > > Scheme isn't especially object-oriented.
> >
> > How about
> > http://askemos2.tc-mw.de/A67bb0753e1676f81983e0ecf3a15b391/XSQLExample
> > (The part about data base connection configuration only applies if you
> > don't use sqlite.)
> >
> > >   The question is whether
> > > that is really required.  The most important aspect about Rails is that
> > > it has decent defaults.  You can just build a database and run Rake
> > > to set up a Rails environment and you have a bare-bones interface to
> > > the database out of the box.  To do things, you need the very minimum
> > > of custom code.  This is the essence of what makes Rails so popular.
> > > I'm not sure if this can be done as easily in a non-object-oriented
> > > environment.  Ruby makes it easy to automatically build objects from
> > > information because it allows you to add members to existing classes.
> > > I think with the Prometheus egg we could do something like this.
> > >
> > > As you see, a lot of stuff is already there.  It's just crying for
> > > someone to put it all together.
> > >
> > > I've been thinking about doing something like this myself since I am
> > > involved in web programming for a company where we are using PHP (yuck!)
> > > and Ruby.  I'd *love* to have something like Rails in Chicken.
> > > The reason I haven't done any work on it is, of course, I'm currently
> > > too busy with some other things that just need to get done before I can
> > > do anything fun like hacking Chicken :(
> > >
> > > If anyone is interested: having a decent userfriendly Scheme CMS would
> > > be *very* useful too :)
> >
> > Well, I personally don't use much more that the wiki, directories
> > (WebDAV), a Forum/RSS, a messaging thingy and a few special applications
> > (for invoices etc.).  We have also some Webmailer, but that's not yet
> > powerful enough to make me ditch evolution.
> >
> > Best regards
> >
> > /Jörg
> >
> >
> > _______________________________________________
> > Chicken-users mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/chicken-users
> >
> 
> 
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/chicken-users
>