It is frequent to find listed among Lisp deficiencies its lack of an
easy mechanism for application delivery other than lisp worlds. Even
renowned lispers as P.Graham cite this as a disadvantage of the
language. I think it should be considered an important advantage in
cases like web apps, where other environments require virtual servers
(Solaris containers, VMware, etc.) to achieve isolation. It would help
having a common interface to network functions in Common Lisp.
Opinions?
On Dec 17, 4:52 pm, ·······@eurogaran.com wrote:
> It is frequent to find listed among Lisp deficiencies its lack of an
> easy mechanism for application delivery other than lisp worlds.
s/Lisp/Java/g
(I mean, have you ever looked at how enterprise Java apps get
delivered. Baroque doesn't really get the flavour of the insane
complexity involved).
k> language. I think it should be considered an important advantage in
k> cases like web apps, where other environments require virtual servers
k> (Solaris containers, VMware, etc.) to achieve isolation.
ehm, you compare Lisp world to vmware machine? for webserver?
afaik nobody stores pics inside lisp's main memory, and also Lisp does not
offer security..
k> It would help having a common interface to network functions in Common
k> Lisp.
i do not see how is this related.. i'm not sure if i'm stupid, or you need
to describe this in details..
> ehm, you compare Lisp world to vmware machine? for webserver?
Yes.
> afaik nobody stores pics inside lisp's main memory,
Static content is usually kept in read-only directories.
I see no reason why it should be different for Lisp.
> and also Lisp does not offer security...
Most the opposite, in fact Lisp web servers have probably the best
security record (no buffer overflows, etc.).
>
> k> It would help having a common interface to network functions in Common
> k> Lisp.
>
> i do not see how is this related.. i'm not sure if i'm stupid, or you need
> to describe this in details..
Not directly related, true, but necessary to popularize Lisp for these
uses.
??>> afaik nobody stores pics inside lisp's main memory,
k> Static content is usually kept in read-only directories.
k> I see no reason why it should be different for Lisp.
ok, explain me then how deploying world + content files is better than
deploying source files + content files, and compile/load source files on the
target?
it can save you few minutes of compile/load time, indeed, but IMHO it's more
tricky to setup (what if yoy need per-node configuration..)
??>> and also Lisp does not offer security...
k> Most the opposite, in fact Lisp web servers have probably the best
k> security record
because nobody uses it? ;)
it's so tempting to use some EVAL in Lisp code..
in one form or another.. people say it's cool to use continuations, but they
consume valuable server memory. what if we'll serialize continuation and
pass it to client, so client can give it us back?
it seems uber-cool, but it's a security breach -- it would be pretty hard to
check that user have not tampered serialized continuation (or closure) to
execute arbitrary code at server.
k> (no buffer overflows, etc.).
really? my SBCL web server crashes from time to time saying something about
GC invariant lost. how you can be sure that malicious users cannot use some
defficiency to trick server to execture arbitrary code?
and, there are even well-documented security holes. for example, ABCL
currently doesn't support binding of socket to specific interface -- it
always binds sockets to all interfaces.
what does it mean? it means that when you start SLIME in ABCL, it's open for
everyone by default. if you start SLIME on web server, your web server is
open for everyone to debug (unless you configure firewall or run it NATed in
vmware).
On Dec 17, 10:00 am, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> ??>> afaik nobody stores pics inside lisp's main memory,
> k> Static content is usually kept in read-only directories.
> k> I see no reason why it should be different for Lisp.
>
> ok, explain me then how deploying world + content files is better than
> deploying source files + content files, and compile/load source files on the
> target?
I guess it's good if you deploy on client server and you don't want
client to see your source code. If you're using your own server it
doesn't make much sense.
>
> it can save you few minutes of compile/load time, indeed, but IMHO it's more
> tricky to setup (what if yoy need per-node configuration..)
>
> ??>> and also Lisp does not offer security...
> k> Most the opposite, in fact Lisp web servers have probably the best
> k> security record
>
> because nobody uses it? ;)
>
> it's so tempting to use some EVAL in Lisp code..
> in one form or another.. people say it's cool to use continuations, but they
> consume valuable server memory.
Depends of the type of the continuations, in weblocks continuations
are just a tool to mimic linear flow and are lighweight, seaside and
UCW (is this true about ucw?) have a long lived continuations, that
persists and could be serialized.
> what if we'll serialize continuation and
> pass it to client, so client can give it us back?
You mean to the web browser, pass the continuations as what ?
> it seems uber-cool, but it's a security breach -- it would be pretty hard to
> check that user have not tampered serialized continuation (or closure) to
> execute arbitrary code at server.
Actually with current state of lisp, we have security through
obscurity, the number of lispers is so small, and number of lispers
who understand your web framework even smaller that you could count
them on your fingers.
>
> k> (no buffer overflows, etc.).
>
> really? my SBCL web server crashes from time to time saying something about
> GC invariant lost. how you can be sure that malicious users cannot use some
> defficiency to trick server to execture arbitrary code?
What kind of app you're running on your web server?
If it's something public please share a link.
cheers
Slobodan
Slobodan Blazeski <·················@gmail.com> wrote:
+---------------
| "Alex Mizrahi" <········@users.sourceforge.net> wrote:
| > in one form or another.. people say it's cool to use continuations,
| > but they consume valuable server memory.
|
| Depends of the type of the continuations, in weblocks continuations
| are just a tool to mimic linear flow and are lighweight, seaside and
| UCW (is this true about ucw?) have a long lived continuations, that
| persists and could be serialized.
+---------------
But that still has the GC/timeout problem. How long do you store
such continuations before you decide that the user is never going
to invoke them? Conversely, if you time one out and abandon it,
what happens when the user comes back from running the kid to
the hospital to get said kid's knee sewn up and finally gets
around to clicking on the "Buy" button, and discovers there's
nothing in their shopping basket any more?
+---------------
| > what if we'll serialize continuation and
| > pass it to client, so client can give it us back?
|
| You mean to the web browser, pass the continuations as what ?
+---------------
As <input type="hidden" name="state" value="whatever"> in HTML forms.
That's what I do.
+---------------
| > it seems uber-cool, but it's a security breach -- it would be pretty
| > hard to check that user have not tampered serialized continuation
| > (or closure) to execute arbitrary code at server.
|
| Actually with current state of lisp, we have security through
| obscurity...
+---------------
What part of the adage "Security by obscurity is no security at all!"
is not clear?!?
You actually don't need any obscurity at all to get security with
client-side ["hidden" form data] serialized continuations. Just
include an HMAC (or other secure keyed hash) over the continuation
as part of the continuation's serialized value. That is quite
sufficient to prevent the user from altering the continuation
and attempting a replay attack that way.
For single-use continuations you will also need a global [to your
server] timestamp/ticket#/serial# to prevent multiple replays as well.
That must also be inside the secure keyed hash.
Finally, if you're afraid your users will try to "decompile" your
continuations and learn something about the server they shouldn't,
you can always encrypt the entire continuation. Just *don't* use
ECB mode!! AES/CTR-mode works well, if the counter includes a
timestamp/ticket#/serial# to make it globally unique. [And even
when encrypting, don't forget the secure keyed hash around the
whole thing...]
-Rob
p.s. And remember, always "encrypt THEN auth", not the other way
around [which is insecure, see any modern crypto text].
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Dec 17, 6:57 pm, ····@rpw3.org (Rob Warnock) wrote:
> Slobodan Blazeski <·················@gmail.com> wrote:
> +---------------
> | "Alex Mizrahi" <········@users.sourceforge.net> wrote:
> | > in one form or another.. people say it's cool to use continuations,
> | > but they consume valuable server memory.
> |
> | Depends of the type of the continuations, in weblocks continuations
> | are just a tool to mimic linear flow and are lighweight, seaside and
> | UCW (is this true about ucw?) have a long lived continuations, that
> | persists and could be serialized.
> +---------------
>
> But that still has the GC/timeout problem. How long do you store
> such continuations before you decide that the user is never going
> to invoke them? Conversely, if you time one out and abandon it,
> what happens when the user comes back from running the kid to
> the hospital to get said kid's knee sewn up and finally gets
> around to clicking on the "Buy" button, and discovers there's
> nothing in their shopping basket any more?
I guess he wont find anything unless he has an user account which he
is logged on , that saves
intermediate state in some wishlist or something like that. I'm not
expert on continuations nor building web apps but for now they look
great for my non-mission critical application.
I'm not interested in adding complex longlived user interaction now.
>
> +---------------
> | > what if we'll serialize continuation and
> | > pass it to client, so client can give it us back?
> |
> | You mean to the web browser, pass the continuations as what ?
> +---------------
>
> As <input type="hidden" name="state" value="whatever"> in HTML forms.
> That's what I do.
Weblocks uses gensysms to id the classes , and widgets.But I won't
call them continuations.
Author could probably explain better
>
> +---------------
> | > it seems uber-cool, but it's a security breach -- it would be pretty
> | > hard to check that user have not tampered serialized continuation
> | > (or closure) to execute arbitrary code at server.
> |
> | Actually with current state of lisp, we have security through
> | obscurity...
> +---------------
>
> What part of the adage "Security by obscurity is no security at all!"
> is not clear?!?
If someone wants to break in my app he will break considering he has
knowledge and time to look for alternatives. Probably even easier he
could make DOS with opening thousands of connections under hunchentoot
weblocks web server. But I'm not making a citybank payment system or
nuke missile control one, so if someone want's to change few articles
or some products let him be. I don't have time nor resources to spend
defending from serious crackers.
>
> You actually don't need any obscurity at all to get security with
> client-side ["hidden" form data] serialized continuations. Just
> include an HMAC (or other secure keyed hash) over the continuation
> as part of the continuation's serialized value. That is quite
> sufficient to prevent the user from altering the continuation
> and attempting a replay attack that way.
>
> For single-use continuations you will also need a global [to your
> server] timestamp/ticket#/serial# to prevent multiple replays as well.
> That must also be inside the secure keyed hash.
>
> Finally, if you're afraid your users will try to "decompile" your
> continuations and learn something about the server they shouldn't,
> you can always encrypt the entire continuation. Just *don't* use
> ECB mode!! AES/CTR-mode works well, if the counter includes a
> timestamp/ticket#/serial# to make it globally unique. [And even
> when encrypting, don't forget the secure keyed hash around the
> whole thing...]
>
> -Rob
>
> p.s. And remember, always "encrypt THEN auth", not the other way
> around [which is insecure, see any modern crypto text].
thanks for the advice
Slobodan
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
RW> You actually don't need any obscurity at all to get security with
RW> client-side ["hidden" form data] serialized continuations. Just
RW> include an HMAC (or other secure keyed hash) over the continuation
RW> as part of the continuation's serialized value. That is quite
RW> sufficient to prevent the user from altering the continuation
RW> and attempting a replay attack that way.
RW> For single-use continuations you will also need a global [to your
RW> server] timestamp/ticket#/serial# to prevent multiple replays as well.
RW> That must also be inside the secure keyed hash.
either you have global list of all continuations you've issued to track
whether they were executed ever,
or user will be able to send you continuation multiple times.
i'm not sure if it's a security problem, probably it can be in some cases..
??>> it's so tempting to use some EVAL in Lisp code..
??>> in one form or another.. people say it's cool to use continuations,
??>> but they consume valuable server memory.
SB> Depends of the type of the continuations, in weblocks continuations
SB> are just a tool to mimic linear flow and are lighweight,
how lightweight they are, and aren't they supposed to be hanging for some
10-20-30 minutes on server?
i.e. your user opens page, reads it for 10 minutes.. you need to have this
cont somewhere, otherwise he would be upset when he continues working with
server.
??>> what if we'll serialize continuation and
??>> pass it to client, so client can give it us back?
SB> You mean to the web browser,
yup
SB> pass the continuations as what ?
as their serialized representation :). i have no clue how it looks like,
probably as some base64 string.
there are libs like cl-store which can serialize arbitrary lisp objects, so
we can serialize stack frames or something like that..
??>> it seems uber-cool, but it's a security breach -- it would be pretty
??>> hard to check that user have not tampered serialized continuation (or
??>> closure) to execute arbitrary code at server.
SB> Actually with current state of lisp, we have security through
SB> obscurity, the number of lispers is so small, and number of lispers
SB> who understand your web framework even smaller that you could count
SB> them on your fingers.
heh, right :). haxors would better hack some weirdly-written PHP apps, than
spend years learning Lisp to crack something..
??>> really? my SBCL web server crashes from time to time saying something
??>> about GC invariant lost. how you can be sure that malicious users
??>> cannot use some defficiency to trick server to execture arbitrary
??>> code?
SB> What kind of app you're running on your web server?
SB> If it's something public please share a link.
the one that crashes SBCL is not mine actually, so i won't tell..
however, i have another one made with ABCL: http://we-tag.info
web stuff is rudimentary there though (so far), interesting part is
underlying algorithms that do text classficiation
On Dec 17, 1:19 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> ??>> it's so tempting to use some EVAL in Lisp code..
> ??>> in one form or another.. people say it's cool to use continuations,
> ??>> but they consume valuable server memory.
> SB> Depends of the type of the continuations, in weblocks continuations
> SB> are just a tool to mimic linear flow and are lighweight,
>
> how lightweight they are, and aren't they supposed to be hanging for some
> 10-20-30 minutes on server?
> i.e. your user opens page, reads it for 10 minutes.. you need to have this
> cont somewhere, otherwise he would be upset when he continues working with
> server.
You should better ask Slava, there was a thread in weblocks group
about continuations in
http://groups.google.com/group/weblocks/browse_thread/thread/9d929ccc21a1b286
so you can post
fallow up or look at the code at
http://common-lisp.net/project/cl-weblocks/darcs/cl-weblocks/src/control-flow/
Another difference is that cl-cont continuations are compiled unlike
arnesi interpreted and so not ment to be seriazible and long lived at.
I posted a little tutorial about using cl-cont at
http://tourdelisp.blogspot.com/2007/12/delimited-continuations-with-cl-cont.html
>
> ??>> what if we'll serialize continuation and
> ??>> pass it to client, so client can give it us back?
> SB> You mean to the web browser,
>
> yup
>
> SB> pass the continuations as what ?
>
> as their serialized representation :). i have no clue how it looks like,
> probably as some base64 string.
> there are libs like cl-store which can serialize arbitrary lisp objects, so
> we can serialize stack frames or something like that..
>
> ??>> it seems uber-cool, but it's a security breach -- it would be pretty
> ??>> hard to check that user have not tampered serialized continuation (or
> ??>> closure) to execute arbitrary code at server.
As I mentioned weblocks continuations are not ment to be serialized,
they're compiled code that just enables you to code through some
higher macros built on top of them, look for examples at below
http://www.defmacro.org/ramblings/continuations-web.html
Second passing continuations as string is a bad idea. Currently
weblocks is using the hook in the mop to communicate via ajax. Back
button in AJAX applications is not the normal thing.Actually weblocks
doesn't even have a notion of pages as it's based on widgets.
Widgets are gensymed closures and responsible to keep their state,
look at the (very simple) demo in http://72.249.76.121/ and note
the html code produced.
How many users it could handle ? Well I don't know but I hope that I
will have a scaling problem with my app, so I don't worry to much
now.
> SB> Actually with current state of lisp, we have security through
> SB> obscurity, the number of lispers is so small, and number of lispers
> SB> who understand your web framework even smaller that you could count
> SB> them on your fingers.
>
> heh, right :). haxors would better hack some weirdly-written PHP apps, than
> spend years learning Lisp to crack something..
User input is very secure in weblocks,
1st traditional regex escaping of input fields,
2nd there is no access to the lisp reader, I tried to snick a backdoor
with parse-float but was denied :)
3rd Lisp strings are just different beasts, try modify some slot in
the demo by entering http://72.249.76.121/ #.(break) nothing
happens
4rd Slava is working on ORM store so there will be no possibility for
SQL injections
I think that weblocks is very secure. It's certainly not perfect but
unless lisp becomes new ruby I don't worry about security at all.
>
> ??>> really? my SBCL web server crashes from time to time saying something
> ??>> about GC invariant lost. how you can be sure that malicious users
> ??>> cannot use some defficiency to trick server to execture arbitrary
> ??>> code?
> SB> What kind of app you're running on your web server?
> SB> If it's something public please share a link.
>
> the one that crashes SBCL is not mine actually, so i won't tell..
> however, i have another one made with ABCL:http://we-tag.info
> web stuff is rudimentary there though (so far),
Cool demo what are using for running it ? I mean what web framework.
> interesting part is
> underlying algorithms that do text classficiation
For lisp it's doing great
language, programming, learning, wikipedia, tutorial
but you should learn it a little bit about gibberish
sgfsdagsdgasd
Results:
business, TV, marketing, sysadmin, mobile
Slobodan
SB> How many users it could handle ? Well I don't know but I hope that I
SB> will have a scaling problem with my app, so I don't worry to much
SB> now.
if you're running Linux, try ab (apache bench), something like ab -n
10000 -c 3 http://you-page.com/lisp
this will throw 10000 requests in 3 threads on application, probably you can
start with lighter numbers. and probably it's better to target page with
something interesting on it.
during the process you can monitor memory usage. i've done such testing with
UCW once, and after some xxxx requests SBCL just said "goodbye" due to heap
exhaustion..
certainly they say "premature optimization is root of all evil", but often
i'm just curious about performance, and also it's good to know to which
extent you can scale.
SB> I think that weblocks is very secure. It's certainly not perfect but
SB> unless lisp becomes new ruby I don't worry about security at all.
quit possibly. some people like kodifik can think that if you have Lisp you
automatically get security.
but you still need careful programming and configuration to get secure.
probably it's a bit easier to make secure applications in Lisp because it's
easier to automate security.
??>> the one that crashes SBCL is not mine actually, so i won't tell..
??>> however, i have another one made with ABCL:http://we-tag.info
??>> web stuff is rudimentary there though (so far),
SB> Cool demo what are using for running it ? I mean what web framework.
ABCL-web: http://abcl-web.sourceforge.net/
demo uses raw request/response stuff, but there are some interesting stuff
involving closures/continuations.
thingie currently available uses macros to create closures that are kinda
continuations, but it doesn't do CPS-transform.
for example:
(action-form
(((:input :name "a"))
((:input :name "b"))
(form-submit "add"))
(with-form-fields (a b) (show-result-page a b)))
when form would be sent by user that will invoke function show-result-page
with parameters a and b. closures are created/memorized for each form/link
on the page.
long time ago i was using CPS-transform stolen from arnesi (it was compiler
that time), and code was looking like this:
(vcase-bind
(gen-student-main-menu-page student section status)
(:view-lecture ((int lecture-id))
(show-lecture lecture-id))
(:start-test ((int test-id))
(show-student-test student test-id))
(:start-practice ()
(practical-task student section))
function gen-student-main-menu-page sends page to client, and the vcase-bind
analyzes which button was pressed, retrieves parameters and calls
appropriate code.
it uses one continuation per page.
> ok, explain me then how deploying world + content files is better than
> deploying source files + content files, and compile/load source files on the
> target?
>
> it can save you few minutes of compile/load time, indeed, but IMHO it's more
> tricky to setup (what if yoy need per-node configuration..)
You omit the additional step of setting up and running the virtualized
server, which was my whole point.
>
> ??>> and also Lisp does not offer security...
> k> Most the opposite, in fact Lisp web servers have probably the best
> k> security record
>
> because nobody uses it? ;)
You seem to.
>
> it's so tempting to use some EVAL in Lisp code..
> in one form or another.. people say it's cool to use continuations, but they
> consume valuable server memory.
Not as much as a virtualized server consumes.
> what if we'll serialize continuation and
> pass it to client, so client can give it us back?
> it seems uber-cool, but it's a security breach -- it would be pretty hard to
> check that user have not tampered serialized continuation (or closure) to
> execute arbitrary code at server.
I am not proposing that.
>
> k> (no buffer overflows, etc.).
>
> really? my SBCL web server crashes from time to time saying something about
> GC invariant lost. how you can be sure that malicious users cannot use some
> defficiency to trick server to execture arbitrary code?
>
There is no magic solution for bad programming. Memory exhaustion
inside a Lisp world remains confined, much as it does in a virtualized
server.
> and, there are even well-documented security holes. for example, ABCL
> currently doesn't support binding of socket to specific interface -- it
> always binds sockets to all interfaces.
> what does it mean? it means that when you start SLIME in ABCL, it's open for
> everyone by default. if you start SLIME on web server, your web server is
> open for everyone to debug (unless you configure firewall or run it NATed in
> vmware).
...which leads us back to the need for a strong set of network
functions.
??>> it can save you few minutes of compile/load time, indeed, but IMHO
??>> it's more tricky to setup (what if yoy need per-node configuration..)
k> You omit the additional step of setting up and running the virtualized
k> server, which was my whole point.
since when is it necessary?
virtualization is used in following cases:
1. you have different weird apps that require different OS settings/OSes and
do not live well with each other.
2. people are using complex configs and require "root" access rights, but
they cannot afford real machine, so they use "virtual" machine.
3. your app needs quite special OS configs, and instead of bothering with
each install you ship virtual image.
4. you need management features like live backup, migration from server to
server etc.
5. you don't trust your app and want better secuity (so attacker at best
will win virtual server, not the real).
if you do not need this stuff, you can happily live w/o virtualization.
you think that lisp world is replacement to 3rd and 5th feature. believe me,
it's not.
3rd feature is about OS config, not about app config. any sane app alone can
be shipped in a form of tarball, for example, and it doesn't matter what is
in this tarball -- source code or lisp core.
however app often requires some environment (other apps and their configs.
DB server, for example), and sometimes it's easier to ship in form of VM --
because our app is only tested with PostgreSQL version 8.1 on Debian, and
requires said changes in config, and .. as you see, such environment is not
related to Lisp world anyhow.
??>> it's so tempting to use some EVAL in Lisp code..
??>> in one form or another.. people say it's cool to use continuations,
??>> but they consume valuable server memory.
k> Not as much as a virtualized server consumes.
virutalized server consumes fixed amount, continuations potentially consume
unlimited.
??>> what if we'll serialize continuation and
??>> pass it to client, so client can give it us back?
??>> it seems uber-cool, but it's a security breach -- it would be pretty
??>> hard to check that user have not tampered serialized continuation (or
??>> closure) to execute arbitrary code at server.
k> I am not proposing that.
but that's what people can do with Lisp.
or they can just call READ, and malicious user will insert #.(cl:delete-file
"boot.ini) into his input. just don't say that Lisp is super-secure. it's
pretty fragile IMO.
??>> really? my SBCL web server crashes from time to time saying something
??>> about GC invariant lost. how you can be sure that malicious users
??>> cannot use some defficiency to trick server to execture arbitrary
??>> code?
k> There is no magic solution for bad programming.
yes, there could be security breaches in any program, including Common Lisp
implementation.
??>> and, there are even well-documented security holes. for example, ABCL
??>> currently doesn't support binding of socket to specific interface --
??>> it always binds sockets to all interfaces. what does it mean? it means
??>> that when you start SLIME in ABCL, it's open for everyone by default.
??>> if you start SLIME on web server, your web server is open for everyone
??>> to debug (unless you configure firewall or run it NATed in vmware).
k> ...which leads us back to the need for a strong set of network
k> functions.
no, this means that if one sets up web-server he needs to configure OS he's
using and other stuff not related to web-server executable itself.
you think "strong set of network functions" should help people to configure
there Cisco router/firewall somehow?
> k> You omit the additional step of setting up and running the virtualized
> k> server, which was my whole point.
> since when is it necessary?
Since my original post was a request for opinions on whether a Lisp
world
can be considered as a substitute (or not) for a virtualized
environment.
But I see that after many disgressions you finally go on to give your
opinion:
> virtualization is used in following cases:
>
> 1. you have different weird apps that require different OS settings/OSes and
> do not live well with each other.
> 2. people are using complex configs and require "root" access rights, but
> they cannot afford real machine, so they use "virtual" machine.
> 3. your app needs quite special OS configs, and instead of bothering with
> each install you ship virtual image.
> 4. you need management features like live backup, migration from server to
> server etc.
> 5. you don't trust your app and want better secuity (so attacker at best
> will win virtual server, not the real).
>
> if you do not need this stuff, you can happily live w/o virtualization.
>
> you think that lisp world is replacement to 3rd and 5th feature. believe me,
> it's not.
That's the opinion I wanted. Thanks.
> 3rd feature is about OS config, not about app config. any sane app alone can
> be shipped in a form of tarball, for example, and it doesn't matter what is
> in this tarball -- source code or lisp core.
> however app often requires some environment (other apps and their configs.
> DB server, for example), and sometimes it's easier to ship in form of VM --
> because our app is only tested with PostgreSQL version 8.1 on Debian, and
> requires said changes in config, and .. as you see, such environment is not
> related to Lisp world anyhow.
In that case, virtualization would be consequence of the DB server
needs,
not the app's needs.
You are taking for granted there can be no Lisp DB server, and that
the
"other apps" will run outside Lisp. Under those premises, you are
right.
> virutalized server consumes fixed amount, continuations potentially consume
> unlimited.
Not if the Lisp world has limitations, as it frequently does.
> ... just don't say that Lisp is super-secure. it's
> pretty fragile IMO.
Thanks again for giving your opinion.
> yes, there could be security breaches in any program, including Common Lisp
> implementation.
We agree.
> k> ...which leads us back to the need for a strong set of network
> k> functions.
>
> no, this means that if one sets up web-server he needs to configure OS he's
> using and other stuff not related to web-server executable itself.
>
> you think "strong set of network functions" should help people to configure
> there Cisco router/firewall somehow?
No, it would just make the Cisco router/firewall superfluous, i.e.
implementable in Lisp.
kodi what are the current way of putting online your lisp web
application in this real world?
Shared servers are out of line because nobody offers lisp
functionality needed. Shared hosting might be an option for Java
& .Net, php or perl . Or some hosts even offer ruby and python. Bu
nobody offers lisp. (Ok maybe http://tech.coop/index and I never heard
of nobody else).
So you need server that you have complete control of, in order to
install sbcl, acl or whatever lisp you're using and whatever else you
need maybe apache as proxy in front of hunchentoot, or postgre for you
interaction with cl-sql etc.
So you're left with dedicated server if you can affort it, (and need
it of course) and VPS as cheaper solution.
Everything else is just dreaming how would it be if lisp ruled the
world . Well it ain't now.
cheers
Slobodan
On Dec 18, 10:21 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> Shared servers are out of line because nobody offers lisp
> functionality needed. Shared hosting might be an option for Java
> & .Net, php or perl . Or some hosts even offer ruby and python. Bu
> nobody offers lisp. (Ok maybehttp://tech.coop/indexand I never heard
> of nobody else).
Just for those interested,
www.nearlyfreespeech.net offers pay as you go storage & bandwidth, and
has clisp (cgi, not persistent server) support.
On Dec 17, 9:16 pm, szergling <···············@gmail.com> wrote:
> On Dec 18, 10:21 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > Shared servers are out of line because nobody offers lisp
> > functionality needed. Shared hosting might be an option for Java
> > & .Net, php or perl . Or some hosts even offer ruby and python. Bu
> > nobody offers lisp. (Ok maybehttp://tech.coop/indexandI never heard
> > of nobody else).
>
> Just for those interested,
>
> www.nearlyfreespeech.netoffers pay as you go storage & bandwidth, and
> has clisp (cgi, not persistent server) support.
Unfortunately I need a threaded lisp, that runs weblocks , but thanks
for the link.
Slobodan
k>>> You omit the additional step of setting up and running the virtualized
k>>> server, which was my whole point.
??>> since when is it necessary?
k> Since my original post was a request for opinions on whether a Lisp
k> world can be considered as a substitute (or not) for a virtualized
k> environment.
this idea seemed so wild to me that i had to clarify if you actually mean
this.
of course Lisp world can be substitute for virtualized envrionment in a
world full of abstract Lisp mainframes mentioned by gavino.
k> In that case, virtualization would be consequence of the DB server
k> needs, not the app's needs.
k> You are taking for granted there can be no Lisp DB server, and that
k> the "other apps" will run outside Lisp. Under those premises, you are
k> right.
i'm not taking it for granted, that's just reality i'm living in.
we have 500 lines documentation about how to configure server, and of this
Lisp-related part is just some 5 lines.
??>> you think "strong set of network functions" should help people to
??>> configure there Cisco router/firewall somehow?
k> No, it would just make the Cisco router/firewall superfluous, i.e.
k> implementable in Lisp.
good luck :)
In article
<····································@p69g2000hsa.googlegroups.com>,
·······@eurogaran.com wrote:
> It is frequent to find listed among Lisp deficiencies its lack of an
> easy mechanism for application delivery other than lisp worlds. Even
> renowned lispers as P.Graham cite this as a disadvantage of the
> language. I think it should be considered an important advantage in
> cases like web apps, where other environments require virtual servers
> (Solaris containers, VMware, etc.) to achieve isolation. It would help
> having a common interface to network functions in Common Lisp.
> Opinions?
Use LispWorks or Allegro CL. Both generate applications.
They can even create DLLs.
--
http://lispm.dyndns.org/