Core Server - CommonLisp Application Server for Linux
evrim
[Core-Server] is an application server developed in Common-Lisp
language. It heavily uses higher order functions, composable data
streams and continuations. These features allow developers to develop
applications in lesser lines of code. Lesser lines of code leads to
easy maintenance and rapid development.
[Core-server] does not use conventional web application development
strategies. As a result, as developers get experience, project
effiency increases. Higher order functions, generic data streams and
macros allows developers to build their own domain specific language
which increases code reuse during and after the development.
Key Features
* Able to use higher order functions, continuations
* Able to build domain specific language
* Rapid development in lesser lines of code
* Easy maintenance
* Built in Prevalence in-memory database (1000x faster than SQL)
* Component/ Web framework ready for Web 2.0 (No more serializing,
deserializing or RPC)
* Built-in support for Dojo Toolkit for building interactive UI's
* Built-in support for FCKeditor
* Full RFC implementations - 822, 2046, 2109, 2388, 2396, 2616,
2617 (no more protocol bugs)
* Runs on Steel Bank Common Lisp (SBCL)
* Easy linux installer for Gentoo, Ubuntu, Debian and Pardus
* Able to control several unix services like:
o Apache Web Server
o Postfix Email Server
o TinyDNS Server
* Suitable for virtual hosting, can be run behind Apache or can
serve directly
* Javascript render library, write in lisp and core-server will
serve it as javascript
* HTML parser and render library
* RSS parser and render library - new!
* CSS render library - new!
* Even HTML can be transformed into javascript to run inside a
browser!
[Core-server] is distributed with GNU GPL v3.0 license.
Stanislaw Halik
> * Able to use higher order functions, continuations
What CPS transformed do you use? I hope it's either not CL-CONT or you
have extended it to transform generic functions with method combinations
like :after or :around. There's some code for it in arnesi.
> * Able to build domain specific language
> * Rapid development in lesser lines of code
> * Easy maintenance
But these are innate Lisp's advantages, no need to list them here.
> * Built in Prevalence in-memory database (1000x faster than SQL)
So it means that the whole data set has to fit into the Lisp image's
memory? Also, SQL features nice query language, optimizing WHERE clauses
and joins.
> * Full RFC implementations - 822, 2046, 2109, 2388, 2396, 2616,
> 2617 (no more protocol bugs)
What about broken browsers, like Microsoft Internet Explorer Business
Enterprise Technology (r) (tm) (c)?
> [Core-server] is distributed with GNU GPL v3.0 license.
That sucks, like, totally. I don't want to pollute my Lisp image with
GPL's viral nature. And I was interested or a minute or two.
There are tons of licenses way more liberal than GPL yet incompatible
with it - BeerWare, 3-clause BSD to name just two. And that's not fault
of these licenses, it's GPL's and Stallman's fault. GNU GPL (LGPL is
fine, though) could just lay down and die.
evrim
Let me try to answer your questions.
On Aug 28, 9:46 pm, Stanislaw Halik <stha...@test123.ltd.pl> wrote:
> thus spoke evrim <evrim...@gmail.com>:
>
> > * Able to use higher order functions, continuations
>
> What CPS transformed do you use? I hope it's either not CL-CONT or you
> have extended it to transform generic functions with method combinations
> like :after or :around. There's some code for it in arnesi.
>
It employs arnesi call/cc for server side continations. For client
side continuations, it has it's own javascript cps conversion functor
located here:
http://labs.core.gen.tr/repos/core-server/src/javascript/cps.lisp
This thread may give you more information about it:
http://groups.google.com/group/core-server/browse_thread/thread/ed1194185e87cd06
> > * Able to build domain specific language
> > * Rapid development in lesser lines of code
> > * Easy maintenance
>
> But these are innate Lisp's advantages, no need to list them here.
Those criterias emphasize how DSL works well while programming web. An
example could be DOM programming documentation:
http://labs.core.gen.tr/#domprogramming
We have several other DSL's included in Core Server:
http://labs.core.gen.tr/repos/core-server/src/markup/
>
> > * Built in Prevalence in-memory database (1000x faster than SQL)
>
> So it means that the whole data set has to fit into the Lisp image's
> memory? Also, SQL features nice query language, optimizing WHERE clauses
> and joins.
This is our current preference. We plan to distribute data across
several servers in future. Core Server is bundled with *easy to use*
CRUD system described here:
http://labs.core.gen.tr/#databaseprogramming
Of course, this does not mean everybody have to use it. One may employ
other options in their project. Here is the documentation that
describes how to use third party libraries:
http://labs.core.gen.tr/#thirdpartylibraries
>
> > * Full RFC implementations - 822, 2046, 2109, 2388, 2396, 2616,
> > 2617 (no more protocol bugs)
>
> What about broken browsers, like Microsoft Internet Explorer Business
> Enterprise Technology (r) (tm) (c)?
Core Server includes implementations of current internet protocols.
This makes Core Server very powerful while interoperating with other
systems. Besides, we are eagerly testing against common browsers (like
those who do not obey standards) and fix bugs.
Finally, here are the basic examples included in Core Server:
http://labs.core.gen.tr/repos/core-server/examples/
> > [Core-server] is distributed with GNU GPL v3.0 license.
>
> That sucks, like, totally. I don't want to pollute my Lisp image with
> GPL's viral nature. And I was interested or a minute or two.
>
> There are tons of licenses way more liberal than GPL yet incompatible
> with it - BeerWare, 3-clause BSD to name just two. And that's not fault
> of these licenses, it's GPL's and Stallman's fault. GNU GPL (LGPL is
> fine, though) could just lay down and die.
We're interested in your opinions about different kind of
licenses. Could you please tell us, in what type of project do you
plan
to use Core-Server ?
CoreServer is being developed since 2006 and deployed since 2007. It's
getting very close to be called as stable so, I suggest all lispers to
install it and give it a try.
Evrim.
André Thieme
> thus spoke evrim <evri...@gmail.com>:
>> * Built in Prevalence in-memory database (1000x faster than SQL)
>
> So it means that the whole data set has to fit into the Lisp image's
> memory? Also, SQL features nice query language, optimizing WHERE clauses
> and joins.
For way less than 10.000 Euro you can buy a server with 72 GB of RAM.
What is the percentage of applications that need more? Also let us not
forget that this number is likely to increase over time, and I am not
speaking about decades here.
If you happen to have a DB of "only" 40 GB size, then why not having
fun with the 3000x speed up of an in-ram db?
Yeah, sql has query language. Only that this is nothing compared to
what Lisp offers you. Does it take more time to write a small Lisp
function that selects the data you would vs. a sql query string?
As soon a relational db system is in the play you will now have to
manage *two* representations of your data, and you need to write
converters for it.
I have myself worked on a Terabyte DB with CL, and today is still not
the time for doing that in-ram. But we are moving into that direction.
I see that there are very very many projects for which 100 GB are big
enough. Taking into account that 20 years ago my computer came with
32 KB of RAM I see the option that in another 20 years even more data
could fit in there.
Who knows, maybe sql DB systems would never have been invented if we
had already in the 70ies TBs of RAM. *shrugs*
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
Rob Warnock
+---------------
| I have myself worked on a Terabyte DB with CL, and today is still not
| the time for doing that in-ram. But we are moving into that direction.
| I see that there are very very many projects for which 100 GB are big
| enough. Taking into account that 20 years ago my computer came with
| 32 KB of RAM I see the option that in another 20 years even more data
| could fit in there.
| Who knows, maybe sql DB systems would never have been invented if we
| had already in the 70ies TBs of RAM. *shrugs*
Not in the 70's, but it's been available for at least for the last
few years. You can buy COTS systems with 1024 CPU cores and *128 TB*
of cache-coherent global tightly-coupled memory ("ccNUMA") *today*:
http://www.sgi.com/products/servers/altix/4000/
...
SGI Altix 4700 incorporates the shared-memory NUMAflex�
architecture, which simplifies software development, workload
management and system administration. It supports up to
1024 cores under one instance of Linux and as much as
128TB of globally shared memory.
...
Yes, Rackspace\\\\\\\\\ (new-)SGI is still selling those, for now.
And they're expensive [SGI Altix uses Intel Itanium CPUs]. But they
exist, and they work.
[Ob. disclaimer: I used to work for the old SGI.]
But your basic point still stands: There are a *lot* of SQL apps out
there for which the whole DB will fit in already-affordable main RAM.
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Stanislaw Halik
> For way less than 10.000 Euro you can buy a server with 72 GB of RAM.
> What is the percentage of applications that need more? Also let us not
> forget that this number is likely to increase over time, and I am not
> speaking about decades here.
That's about 40k Polish złotys. Quite a lot of money, about 4 times of
what a person working for a minimum wage makes in a year (about 1k
złotys in a month).
Usually people have access to regular amd64 PCs running as servers, with
4 slots for RAM. Put 2 GB in each and that makes 8 GB. It's quite enough
for a database when noticing that large data (images, files etc.) can be
stored in the file system. Then an average PC can easily fit a large
database.
Won't do for a shared hosting environment, but definitely will for a
dedicated server.
--
polscy Lispnicy, łączmy się -- #lisp-pl na freenode
Stanislaw Halik
> We're interested in your opinions about different kind of licenses.
> Could you please tell us, in what type of project do you plan to use
> Core-Server ?
I don't have a specific project in mind, but I'm looking for a web
framework allowing me to use my code with different protocols, e.g.
XMLRPC, HTTP, maybe even IRC without writing application code for each
one of them.
I haven't done much web programming because most frameworks require me
to write JavaScript code tailored to each and every Web browser there
is, if I only want to have some kind of client-side scripting.
I also have reservations towards continuation-based frameworks. Once
watched a lispcast (don't remember the author), and every time the guy
made an error, he first refreshed the page, got the error again, then
said he had to purge the session. Continuations can't be updated when
stored inside the session by mere C-c as it is with traditional
asynchronous frameworks.
Daniel Janus
napisaďż˝/a:
> Yeah, sql has query language. Only that this is nothing compared to
> what Lisp offers you. Does it take more time to write a small Lisp
> function that selects the data you would vs. a sql query string?
In spite of my fondness of Lisp and its sheer power, I'm afraid I have
to answer this question in the affirmative. Certainly, this is true
in case of really simple queries, such as "select * from user where
user_name = 'JohnDoe'".
In real-world projects, though, there is a plethora of features that SQL
can offer, which are not quite as easily achievable in your language,
not even in Lisp. It is not uncommon to encounter a SELECT query longer
than a couple of screenfuls -- and that's due to the very nature of the
data in question, not because the programmer was not clever enough to
express the query in a simpler way; it just can't be made simpler. Take
a look at the primitives out of which an optimizer constructs query
plans: in addition to your ordinary sequential scans, there are
B-tree index scans, hash scans, hash left joins, aggregations,
inverted indices (for full-text search, with efficient Golomb-code
representations), ... cl-containers is a step in the right direction,
but raise your hands, prevalence users: how many of you use it to its
full extent, and get it right?
So in some cases, you won't get very far without a data retrieval
DSL. And SQL is definitely far from an ideal DSL of this sort, but
more often than not, it's just good enough, and the most robust
option available.
--
Daniel 'Nathell' Janus, mov...@nathell.korpus.pl, http://danieljanus.pl
create_initial_thread(initial_function);
lose("CATS. CATS ARE NICE.\n");
-- Steel Bank Common Lisp, sbcl/runtime/runtime.c:425
André Thieme
> Dnia 30.08.2009 André Thieme <address.good.un...@justmail.de>
> napisał/a:
>
>> Yeah, sql has query language. Only that this is nothing compared to
>> what Lisp offers you. Does it take more time to write a small Lisp
>> function that selects the data you would vs. a sql query string?
>
> In spite of my fondness of Lisp and its sheer power, I'm afraid I have
> to answer this question in the affirmative. Certainly, this is true
> in case of really simple queries, such as "select * from user where
> user_name = 'JohnDoe'".
Yes, both, in sql and Lisp, this can be expressed easily and won't take
too much time to develop.
> In real-world projects, though, there is a plethora of features that SQL
> can offer, which are not quite as easily achievable in your language,
> not even in Lisp. It is not uncommon to encounter a SELECT query longer
> than a couple of screenfuls -- and that's due to the very nature of the
> data in question, not because the programmer was not clever enough to
> express the query in a simpler way; it just can't be made simpler.
Do you think that two screens SQL would require 11 screes full of Lisp
code to achieve the same thing?
In two screens of Lisp code a lot of data can be operated out of Lisp
data structures.
Lot‘s of joins won't be needed anymore. When I want to see what goods
a customer bought, then in sql I will have to join some tables.
In Lisp we would look into the goods slot of the customer object. There
they already are.
> So in some cases, you won't get very far without a data retrieval
> DSL. And SQL is definitely far from an ideal DSL of this sort, but
> more often than not, it's just good enough, and the most robust
> option available.
A lot of work has gone into relational DB systems, they are indeed
mature. I don‘t want to convince anyone that we now have to shut them
down and do everything with in-ram DBs. It is just IMO an interesting
option to have.
Have the object model you want, delete the dependency of the db system,
use any algorithm and query language you want, run 5000x faster queries,
don't force your partners to license DB servers, and so on.