chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: F. Wittenberger
Subject: OT: Re: [Chicken-users] rails-like framework
Date: Sat, 22 Apr 2006 16:21:02 +0200

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]