[Top][All Lists]

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

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

From: Shawn Rutledge
Subject: Re: OT: Re: [Chicken-users] rails-like framework
Date: Mon, 24 Apr 2006 15:12:31 -0700

Well I see the idea of calling a web framework an OS is not new:

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

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?
 These are the reasons I think maybe a human-readable S-expression
form is good for persistence.  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.)

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 ( ).  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)?
> (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 (, 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 , and
> . Those 96.2982% write availability seen here
> 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
> > ( 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
> (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

reply via email to

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