So how do things like cl-weblocks and arc work? I thought there was an
issue with scaling -- one cannot be sure the same machine handles the
user each time. Or can one? Can one force a page to come back to the
same machine and process? Or are these systems sneakily faking closures?
Puzzled.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
It simply saves closures into user session.
This have several potential problems.
Like huge memory hog in case of overusing closures, especially in big
multipage tables, problems with back button, and of course scaling to
multiserver farm.
Also weblock is strictly html+js frontend. It has loads of cool
components that generate crazy dhtml, but if you are using Flex, it is
all useless.
I ended up using simple hunchentoot with Flex frontend and json for
data transfer protocol, and cl-who, cl-emb for html generation.
On Mar 11, 9:17 pm, Ken Tilton <···········@optonline.net> wrote:
> So how do things like cl-weblocks and arc work? I thought there was an
> issue with scaling -- one cannot be sure the same machine handles the
> user each time. Or can one? Can one force a page to come back to the
> same machine and process? Or are these systems sneakily faking closures?
One option is to encode the ID of the server that created the session
into the user's session ID, and pass that session ID in requests. Then
use a hardware load balancer (or software load balancer I guess) that
can recognize that value and make sure it always gets directed to the
same server. I have no idea if arc or cl-weblocks support this though.
- Peter
petere wrote:
> On Mar 11, 9:17 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>So how do things like cl-weblocks and arc work? I thought there was an
>>issue with scaling -- one cannot be sure the same machine handles the
>>user each time. Or can one? Can one force a page to come back to the
>>same machine and process? Or are these systems sneakily faking closures?
>
>
> One option is to encode the ID of the server that created the session
> into the user's session ID, and pass that session ID in requests. Then
> use a hardware load balancer (or software load balancer I guess) that
> can recognize that value and make sure it always gets directed to the
> same server.
I gather these deals do not add too the latency?
> I have no idea if arc or cl-weblocks support this though.
I guess as long as there is no in principle barrier to scaling, that is
all that matters.
thx all--
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
If you introduce State on the server to be kept across requests (even
a simple "user session" with only data and no closures), you *must*
have a mechanism to a. keep the user on the same server across
multiple HTTP requests, OR b. have a way to "propagate" state from a
server to another, "following" the user (it doesn't really have to be
physically propagated of course, it just has to be shared, e.g. on a
common DB). I think (by intuition only, I don't have experience about
this) that solution b. is somewhat crippled and does not scale very
well. Some frameworks (namely asp.net) encode components' (i.e.
widgets in weblocks et al. parlance) state as a string in the page to
be sent back and forth with each request. This has drawbacks in terms
of bandwidth and poor security (you can easily decode that string
unless you encrypt it), but still it doesn't completely solve the
scalability problem unless you, the programmer, guarantee that all of
your application state is either saved on a DB or sent back and forth
to the client using that mechanism. (I don't really know how asp.net
handles user sessions and whether they are "shared" among multiple
servers).
So probably for most (Lisp or not) complex web frameworks, option a.
is the only viable choice. Unless I missed something, which is not so
improbable :)
On Mar 12, 7:36 am, Ken Tilton <···········@optonline.net> wrote:
> petere wrote:
> > On Mar 11, 9:17 pm, Ken Tilton <···········@optonline.net> wrote:
>
> >>So how do things like cl-weblocks and arc work? I thought there was an
> >>issue with scaling -- one cannot be sure the same machine handles the
> >>user each time. Or can one? Can one force a page to come back to the
> >>same machine and process? Or are these systems sneakily faking closures?
>
> > One option is to encode the ID of the server that created the session
> > into the user's session ID, and pass that session ID in requests. Then
> > use a hardware load balancer (or software load balancer I guess) that
> > can recognize that value and make sure it always gets directed to the
> > same server.
>
> I gather these deals do not add too the latency?
>
> > I have no idea if arc or cl-weblocks support this though.
>
> I guess as long as there is no in principle barrier to scaling, that is
> all that matters.
>
> thx all--
>
> kenny
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
Alessio wrote:
snip
> b. have a way to "propagate" state from a
> server to another, "following" the user (it doesn't really have to be
> physically propagated of course, it just has to be shared, e.g. on a
> common DB).
Maybe we're talking about two different things, but ANY time you are
conversing across a socket you are physically propagating data (not
sharing it).
> I think (by intuition only, I don't have experience about
> this) that solution b. is somewhat crippled and does not scale very
> well.
It works pretty well in practice as long as you don't try to save large
data tables, for example, and there's really no need to do this.
> Some frameworks (namely asp.net) encode components' (i.e.
> widgets in weblocks et al. parlance) state as a string in the page to
> be sent back and forth with each request. This has drawbacks in terms
> of bandwidth and poor security (you can easily decode that string
> unless you encrypt it),
You don't store sensitive information in page state, so there is no
need to encode it. Page state is only a convenience feature that makes
recreating the page easier the next time the page is built.
> but still it doesn't completely solve the
> scalability problem unless you, the programmer, guarantee that all of
> your application state is either saved on a DB or sent back and forth
> to the client using that mechanism. (I don't really know how asp.net
> handles user sessions and whether they are "shared" among multiple
> servers).
snip
asp.net allows you to save state in at least four different ways:
1. you can have state automatically encoded in a base64 string
within a hidden field on the web page.
PROs: it scales if you are careful to pick the right components to
save state (don't try to save state of all portions of components
with large quantities of data)
CONs: bandwidth hog; jamming this amount of crap across a wire
eventually causes an error because a single data-transmission error
can render the state information unusable---some shops don't
experience this problem, others do.
2. in-memory state storage
PROs: fastest; works well on small sites; simple; saves gobs of bandwidth
CONs: doesn't scale, but this is really not much of an issue because
once you reach that threshold you can easily change strategies by
changing one or two lines in the sites web.config file, save the file,
and IIS will automatically restart the service with the new settings.
3. database storage (can be a conventional RDBMS or a db that
MS provides just for this purpose for free)
PROs: scales as long as you wisely choose which items to save; can be
used by multiple servers
CONs: slower than saving state in-memory; can add a lot of network and
db traffic if you try to naively save state of all large components
4. asp.net allows you to use custom state code
PROs: this gives you the option, for example, of having the page restore
state in a more automated fashion (asp.net has trouble restoring state
to a few controls);
allows you to extend existing asp.net state classes so that you only
have to rewrite the portions that pertain to your problem.
CONs: more code to write.
I realize that this is not an asp.net forum, but it's good to know how
competing technologies work, and in my opinion, the Lisp web frameworks
that only use the in-memory model to maintain state should be used with
caution. Every web framework that expects to handle large volumes of
traffic needs a serialization strategy.
On Mar 12, 1:53 pm, vanekl <·····@acd.net> wrote:
> Alessio wrote:
>
> snip
>
> > b. have a way to "propagate" state from a
> > server to another, "following" the user (it doesn't really have to be
> > physically propagated of course, it just has to be shared, e.g. on a
> > common DB).
>
> Maybe we're talking about two different things, but ANY time you are
> conversing across a socket you are physically propagating data (not
> sharing it).
Point taken :) sharing does not mean much in this context.
> > I think (by intuition only, I don't have experience about
> > this) that solution b. is somewhat crippled and does not scale very
> > well.
>
> It works pretty well in practice as long as you don't try to save large
> data tables, for example, and there's really no need to do this.
Good to know that...
> > Some frameworks (namely asp.net) encode components' (i.e.
> > widgets in weblocks et al. parlance) state as a string in the page to
> > be sent back and forth with each request. This has drawbacks in terms
> > of bandwidth and poor security (you can easily decode that string
> > unless you encrypt it),
>
> You don't store sensitive information in page state, so there is no
> need to encode it. Page state is only a convenience feature that makes
> recreating the page easier the next time the page is built.
Here I have a different opinion. You don't store sensitive information
in page state precisely because it's unsafe to do so: this is not a
real solution to the problem, it's only realizing the existence of the
problem and avoiding it. Also, I don't see page state as "only a
convenience feature", no more than I consider sessions to be a
convenience feature; they're two methods for doing roughly the same
thing, with different pros and cons of course.
> > but still it doesn't completely solve the
> > scalability problem unless you, the programmer, guarantee that all of
> > your application state is either saved on a DB or sent back and forth
> > to the client using that mechanism. (I don't really know how asp.net
> > handles user sessions and whether they are "shared" among multiple
> > servers).
>
> snip
>
> asp.net allows you to save state in at least four different ways:
>
> 1. you can have state automatically encoded in a base64 string
> within a hidden field on the web page.
>
> PROs: it scales if you are careful to pick the right components to
> save state (don't try to save state of all portions of components
> with large quantities of data)
> CONs: bandwidth hog; jamming this amount of crap across a wire
> eventually causes an error because a single data-transmission error
> can render the state information unusable---some shops don't
> experience this problem, others do.
I hadn't thought about transmission errors... I like it even less
now :) About not saving huge state... IMHO that's good advice to
follow in any situation...
> 2. in-memory state storage
>
> PROs: fastest; works well on small sites; simple; saves gobs of bandwidth
> CONs: doesn't scale, but this is really not much of an issue because
> once you reach that threshold you can easily change strategies by
> changing one or two lines in the sites web.config file, save the file,
> and IIS will automatically restart the service with the new settings.
>
> 3. database storage (can be a conventional RDBMS or a db that
> MS provides just for this purpose for free)
>
> PROs: scales as long as you wisely choose which items to save; can be
> used by multiple servers
> CONs: slower than saving state in-memory; can add a lot of network and
> db traffic if you try to naively save state of all large components
these are what I was thinking about in my original post. Of course
saving closures on a DB isn't very straightforward :)
> 4. asp.net allows you to use custom state code
>
> PROs: this gives you the option, for example, of having the page restore
> state in a more automated fashion (asp.net has trouble restoring state
> to a few controls);
> allows you to extend existing asp.net state classes so that you only
> have to rewrite the portions that pertain to your problem.
> CONs: more code to write.
I see point 4 can be useful & cool, but it's quite orthogonal to the
problem... I mean, if you write the code yourself you still have to
save state in memory, db or page state (or somewhere else, e.g. in
files?)
> I realize that this is not an asp.net forum, but it's good to know how
> competing technologies work, and in my opinion, the Lisp web frameworks
> that only use the in-memory model to maintain state should be used with
> caution. Every web framework that expects to handle large volumes of
> traffic needs a serialization strategy.
I completely agree. BTW I'm working on a (crappy) web framework
myself, just for fun, and for now I'm saving everything in memory (but
trying to share among sessions as much state as possible). Even if
I'll never have the time to do it :) I think its current architecture
would play quite nice with serialization... and now that someone
mentioned cl-store... ah, that's distracting me from my work! Let's
return to Java... :(
cheers
Alessio Stalla
I'm going to top-post because... well, just because.
Alessio, I think we're pretty much in agreement, so I'm
not going to pick nits in the c.l.l. tradition.
But I made one mistake in my previous post that requires
correction:
when I said every framework that is going to be used on
high-traffic sites should have a serialization strategy,
I also should have added that routing to the server that
maintains in-memory state structures is also a perfectly
valid strategy.
cheers right back to yuh,
-lv
Alessio wrote:
> On Mar 12, 1:53 pm, vanekl <·····@acd.net> wrote:
>> Alessio wrote:
>>
>> snip
>>
>>> b. have a way to "propagate" state from a
>>> server to another, "following" the user (it doesn't really have to be
>>> physically propagated of course, it just has to be shared, e.g. on a
>>> common DB).
>> Maybe we're talking about two different things, but ANY time you are
>> conversing across a socket you are physically propagating data (not
>> sharing it).
>
> Point taken :) sharing does not mean much in this context.
>
>>> I think (by intuition only, I don't have experience about
>>> this) that solution b. is somewhat crippled and does not scale very
>>> well.
>> It works pretty well in practice as long as you don't try to save large
>> data tables, for example, and there's really no need to do this.
>
> Good to know that...
>
>>> Some frameworks (namely asp.net) encode components' (i.e.
>>> widgets in weblocks et al. parlance) state as a string in the page to
>>> be sent back and forth with each request. This has drawbacks in terms
>>> of bandwidth and poor security (you can easily decode that string
>>> unless you encrypt it),
>> You don't store sensitive information in page state, so there is no
>> need to encode it. Page state is only a convenience feature that makes
>> recreating the page easier the next time the page is built.
>
> Here I have a different opinion. You don't store sensitive information
> in page state precisely because it's unsafe to do so: this is not a
> real solution to the problem, it's only realizing the existence of the
> problem and avoiding it. Also, I don't see page state as "only a
> convenience feature", no more than I consider sessions to be a
> convenience feature; they're two methods for doing roughly the same
> thing, with different pros and cons of course.
>
>>> but still it doesn't completely solve the
>>> scalability problem unless you, the programmer, guarantee that all of
>>> your application state is either saved on a DB or sent back and forth
>>> to the client using that mechanism. (I don't really know how asp.net
>>> handles user sessions and whether they are "shared" among multiple
>>> servers).
>> snip
>>
>> asp.net allows you to save state in at least four different ways:
>>
>> 1. you can have state automatically encoded in a base64 string
>> within a hidden field on the web page.
>>
>> PROs: it scales if you are careful to pick the right components to
>> save state (don't try to save state of all portions of components
>> with large quantities of data)
>> CONs: bandwidth hog; jamming this amount of crap across a wire
>> eventually causes an error because a single data-transmission error
>> can render the state information unusable---some shops don't
>> experience this problem, others do.
>
> I hadn't thought about transmission errors... I like it even less
> now :) About not saving huge state... IMHO that's good advice to
> follow in any situation...
>
>> 2. in-memory state storage
>>
>> PROs: fastest; works well on small sites; simple; saves gobs of bandwidth
>> CONs: doesn't scale, but this is really not much of an issue because
>> once you reach that threshold you can easily change strategies by
>> changing one or two lines in the sites web.config file, save the file,
>> and IIS will automatically restart the service with the new settings.
>>
>> 3. database storage (can be a conventional RDBMS or a db that
>> MS provides just for this purpose for free)
>>
>> PROs: scales as long as you wisely choose which items to save; can be
>> used by multiple servers
>> CONs: slower than saving state in-memory; can add a lot of network and
>> db traffic if you try to naively save state of all large components
>
> these are what I was thinking about in my original post. Of course
> saving closures on a DB isn't very straightforward :)
>
>> 4. asp.net allows you to use custom state code
>>
>> PROs: this gives you the option, for example, of having the page restore
>> state in a more automated fashion (asp.net has trouble restoring state
>> to a few controls);
>> allows you to extend existing asp.net state classes so that you only
>> have to rewrite the portions that pertain to your problem.
>> CONs: more code to write.
>
> I see point 4 can be useful & cool, but it's quite orthogonal to the
> problem... I mean, if you write the code yourself you still have to
> save state in memory, db or page state (or somewhere else, e.g. in
> files?)
>
>> I realize that this is not an asp.net forum, but it's good to know how
>> competing technologies work, and in my opinion, the Lisp web frameworks
>> that only use the in-memory model to maintain state should be used with
>> caution. Every web framework that expects to handle large volumes of
>> traffic needs a serialization strategy.
>
> I completely agree. BTW I'm working on a (crappy) web framework
> myself, just for fun, and for now I'm saving everything in memory (but
> trying to share among sessions as much state as possible). Even if
> I'll never have the time to do it :) I think its current architecture
> would play quite nice with serialization... and now that someone
> mentioned cl-store... ah, that's distracting me from my work! Let's
> return to Java... :(
>
> cheers
> Alessio Stalla
vanekl wrote:
>> BTW I'm working on a (crappy) web framework
>> myself...
Normally we prefer noobs to reinvent an entire Lisp from scratch,
failing that to do a dataflow hack like Cells... oh, OK, I think we can
add web frameworks to the list of approved noob wheel reinventions, we
already have a lot of those. As long as we have the hood up...
Any other reinventions we should add? Ah, yes, bindings to Gtk or Tk or
anything OpenGL related, can't have enough of those. And binding
/generators/ are popular, I know of three, no, four....
Am I going about this wrong? Should we take something nice and stable
and substandardized and get the noobs to work on confusing things?
Anyone up for a CFFI-alike? A third defsystem to go with ASDF and
mk:defsystem?
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
somehow the attribution to this quote got skewed.
I'm not working on a web framework.
This is Alessio's statement:
> vanekl wrote:
>>> BTW I'm working on a (crappy) web framework
>>> myself...
>
Ken Tilton wrote:
> Normally we prefer noobs to reinvent an entire Lisp from scratch,
> failing that to do a dataflow hack like Cells... oh, OK, I think we can
> add web frameworks to the list of approved noob wheel reinventions, we
> already have a lot of those. As long as we have the hood up...
>
> Any other reinventions we should add? Ah, yes, bindings to Gtk or Tk or
> anything OpenGL related, can't have enough of those. And binding
> /generators/ are popular, I know of three, no, four....
>
> Am I going about this wrong? Should we take something nice and stable
> and substandardized and get the noobs to work on confusing things?
>
> Anyone up for a CFFI-alike? A third defsystem to go with ASDF and
> mk:defsystem?
>
> hth, kenny
Personally, I think there's going to be several
mini-renaissances in computing shortly. And one of them is
going to be re-envisioning current persistence strategies.
RDBMS are too brittle; OODBMS didn't add enough to make
them worthwhile. Google showed that fast, distributed,
high-available persistence is possible, but hasn't solved
the join problem yet (except in the most brute-force
manner). C# V3 added Linq, but it's proprietary and not
fully baked. People have started adding a layer between
their applications and the RDBMS just to make the db more
amenable to the newer style of rapid application development
where the schema is constantly in flux.
If a standard network layer could be built that works with
all major Lisps and all major OS platforms, there's no
reason why noobs cannot try to attack this problem with
CL. It's not an easy problem, though. CouchDB is having
efficiency problems. Elephant, as far as I know, has bogged
down. But the changing landscape of computing where there
are large numbers of commodity CPUs with multiple cores and
high-speed interconnects is going to open up opportunities
for the person who correctly re-envisions the next iteration
of persistence. The impedance mismatch between programming
language and persistence mechanism is just too great to
ignore forever. Sure, we have things that work, but they
could be made better in several ways, and will be made
better.
This response is probably too on-the-nose for the question
you posted. And to tell you the truth, I can't even tell
whether you are poking fun at the noobs who continually
reinvent the wheel, or what, so I hope it doesn't matter.
-lv
vanekl wrote:
>
>
>
> somehow the attribution to this quote got skewed.
> I'm not working on a web framework.
> This is Alessio's statement:
>
>> vanekl wrote:
>>
>>>> BTW I'm working on a (crappy) web framework
>>>> myself...
>>
>>
>
> Ken Tilton wrote:
>
>> Normally we prefer noobs to reinvent an entire Lisp from scratch,
>> failing that to do a dataflow hack like Cells... oh, OK, I think we
>> can add web frameworks to the list of approved noob wheel
>> reinventions, we already have a lot of those. As long as we have the
>> hood up...
>>
>> Any other reinventions we should add? Ah, yes, bindings to Gtk or Tk
>> or anything OpenGL related, can't have enough of those. And binding
>> /generators/ are popular, I know of three, no, four....
>>
>> Am I going about this wrong? Should we take something nice and stable
>> and substandardized and get the noobs to work on confusing things?
>>
>> Anyone up for a CFFI-alike? A third defsystem to go with ASDF and
>> mk:defsystem?
>>
>> hth, kenny
>
>
>
> Personally, I think there's going to be several
> mini-renaissances in computing shortly. And one of them is
> going to be re-envisioning current persistence strategies.
Awesome. Persistence. Elepehant, Rucksack, cl-store....
> RDBMS are too brittle; OODBMS didn't add enough to make
> them worthwhile.
Right, still too strait-jackety for Lisp.
Google showed that fast, distributed,
> high-available persistence is possible, but hasn't solved
> the join problem yet (except in the most brute-force
> manner). C# V3 added Linq, but it's proprietary and not
> fully baked. People have started adding a layer between
> their applications and the RDBMS just to make the db more
> amenable to the newer style of rapid application development
> where the schema is constantly in flux.
R! D! F!
?
>
> If a standard network layer could be built that works with
> all major Lisps and all major OS platforms, there's no
> reason why noobs cannot try to attack this problem with
> CL. It's not an easy problem, though. CouchDB is having
> efficiency problems. Elephant, as far as I know, has bogged
> down. But the changing landscape of computing where there
> are large numbers of commodity CPUs with multiple cores and
> high-speed interconnects is going to open up opportunities
> for the person who correctly re-envisions the next iteration
> of persistence. The impedance mismatch between programming
> language and persistence mechanism is just too great to
> ignore forever. Sure, we have things that work, but they
> could be made better in several ways, and will be made
> better.
>
> This response is probably too on-the-nose for the question
> you posted. And to tell you the truth, I can't even tell
> whether you are poking fun at the noobs who continually
> reinvent the wheel, or what, so I hope it doesn't matter.
Let's start with Redland bindings.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton wrote:
>
>
> vanekl wrote:
>>
>>
>>
>> somehow the attribution to this quote got skewed.
>> I'm not working on a web framework.
>> This is Alessio's statement:
>>
>>> vanekl wrote:
>>>
>>>>> BTW I'm working on a (crappy) web framework
>>>>> myself...
>>>
>>>
>>
>> Ken Tilton wrote:
>>
>>> Normally we prefer noobs to reinvent an entire Lisp from scratch,
>>> failing that to do a dataflow hack like Cells... oh, OK, I think we
>>> can add web frameworks to the list of approved noob wheel
>>> reinventions, we already have a lot of those. As long as we have the
>>> hood up...
>>>
>>> Any other reinventions we should add? Ah, yes, bindings to Gtk or Tk
>>> or anything OpenGL related, can't have enough of those. And binding
>>> /generators/ are popular, I know of three, no, four....
>>>
>>> Am I going about this wrong? Should we take something nice and stable
>>> and substandardized and get the noobs to work on confusing things?
>>>
>>> Anyone up for a CFFI-alike? A third defsystem to go with ASDF and
>>> mk:defsystem?
>>>
>>> hth, kenny
>>
>>
>>
>> Personally, I think there's going to be several
>> mini-renaissances in computing shortly. And one of them is
>> going to be re-envisioning current persistence strategies.
>
> Awesome. Persistence. Elepehant, Rucksack, cl-store....
>
>> RDBMS are too brittle; OODBMS didn't add enough to make
>> them worthwhile.
>
> Right, still too strait-jackety for Lisp.
>
> Google showed that fast, distributed,
>> high-available persistence is possible, but hasn't solved
>> the join problem yet (except in the most brute-force
>> manner). C# V3 added Linq, but it's proprietary and not
>> fully baked. People have started adding a layer between
>> their applications and the RDBMS just to make the db more
>> amenable to the newer style of rapid application development
>> where the schema is constantly in flux.
>
> R! D! F!
>
> ?
>
>>
>> If a standard network layer could be built that works with
>> all major Lisps and all major OS platforms, there's no
>> reason why noobs cannot try to attack this problem with
>> CL. It's not an easy problem, though. CouchDB is having
>> efficiency problems. Elephant, as far as I know, has bogged
>> down. But the changing landscape of computing where there
>> are large numbers of commodity CPUs with multiple cores and
>> high-speed interconnects is going to open up opportunities
>> for the person who correctly re-envisions the next iteration
>> of persistence. The impedance mismatch between programming
>> language and persistence mechanism is just too great to
>> ignore forever. Sure, we have things that work, but they
>> could be made better in several ways, and will be made
>> better.
>>
>> This response is probably too on-the-nose for the question
>> you posted. And to tell you the truth, I can't even tell
>> whether you are poking fun at the noobs who continually
>> reinvent the wheel, or what, so I hope it doesn't matter.
>
> Let's start with Redland bindings.
>
> kenny
I think the next step up in persistence is going to have to:
1. make persistence as transparent to the
programming language as possible; plays well with objects;
2. allow for either flexible schema, or no schema, a la
everything's a triple;
3. distributed across servers; servers can "attach/detach"
to db network without pain.
4. redundant; fault-tolerant; auto-failover;
5. saves historical data, doesn't overwrite it;
6. as responsive as traditional relational systems;
7. does not require centralized write server;
8. db designed to morph from version to version, not
require agonizing re-writes like some rdbms require
<cough>sql svr</cough>.
RDF addresses only a small subset of those issues.
Google's BigTable shows more promise, IMNSHO.
The thing that bumps RDBMSs off that pedestal
will be bold, and will make business sense.
Migrating dbs is painful and wont be done unless
there's a large number of advantages over the
current de facto solutions. I'm not convinced
RDF running on RAID is it.
-lv
vanekl wrote:
> Ken Tilton wrote:
>
>>
>>
>> vanekl wrote:
>>
>>>
>>>
>>>
>>> somehow the attribution to this quote got skewed.
>>> I'm not working on a web framework.
>>> This is Alessio's statement:
>>>
>>>> vanekl wrote:
>>>>
>>>>>> BTW I'm working on a (crappy) web framework
>>>>>> myself...
>>>>
>>>>
>>>>
>>>
>>> Ken Tilton wrote:
>>>
>>>> Normally we prefer noobs to reinvent an entire Lisp from scratch,
>>>> failing that to do a dataflow hack like Cells... oh, OK, I think we
>>>> can add web frameworks to the list of approved noob wheel
>>>> reinventions, we already have a lot of those. As long as we have the
>>>> hood up...
>>>>
>>>> Any other reinventions we should add? Ah, yes, bindings to Gtk or Tk
>>>> or anything OpenGL related, can't have enough of those. And binding
>>>> /generators/ are popular, I know of three, no, four....
>>>>
>>>> Am I going about this wrong? Should we take something nice and
>>>> stable and substandardized and get the noobs to work on confusing
>>>> things?
>>>>
>>>> Anyone up for a CFFI-alike? A third defsystem to go with ASDF and
>>>> mk:defsystem?
>>>>
>>>> hth, kenny
>>>
>>>
>>>
>>>
>>> Personally, I think there's going to be several
>>> mini-renaissances in computing shortly. And one of them is
>>> going to be re-envisioning current persistence strategies.
>>
>>
>> Awesome. Persistence. Elepehant, Rucksack, cl-store....
>>
>>> RDBMS are too brittle; OODBMS didn't add enough to make
>>> them worthwhile.
>>
>>
>> Right, still too strait-jackety for Lisp.
>>
>> Google showed that fast, distributed,
>>
>>> high-available persistence is possible, but hasn't solved
>>> the join problem yet (except in the most brute-force
>>> manner). C# V3 added Linq, but it's proprietary and not
>>> fully baked. People have started adding a layer between
>>> their applications and the RDBMS just to make the db more
>>> amenable to the newer style of rapid application development
>>> where the schema is constantly in flux.
>>
>>
>> R! D! F!
>>
>> ?
>>
>>>
>>> If a standard network layer could be built that works with
>>> all major Lisps and all major OS platforms, there's no
>>> reason why noobs cannot try to attack this problem with
>>> CL. It's not an easy problem, though. CouchDB is having
>>> efficiency problems. Elephant, as far as I know, has bogged
>>> down. But the changing landscape of computing where there
>>> are large numbers of commodity CPUs with multiple cores and
>>> high-speed interconnects is going to open up opportunities
>>> for the person who correctly re-envisions the next iteration
>>> of persistence. The impedance mismatch between programming
>>> language and persistence mechanism is just too great to
>>> ignore forever. Sure, we have things that work, but they
>>> could be made better in several ways, and will be made
>>> better.
>>>
>>> This response is probably too on-the-nose for the question
>>> you posted. And to tell you the truth, I can't even tell
>>> whether you are poking fun at the noobs who continually
>>> reinvent the wheel, or what, so I hope it doesn't matter.
>>
>>
>> Let's start with Redland bindings.
>>
>> kenny
>
>
> I think the next step up in persistence is going to have to:
>
> 1. make persistence as transparent to the
> programming language as possible; plays well with objects;
But I think objects are wrong whether they are persistent or not, I say
throw them out too as long as we have the hood up. They are legacy, they
failed, off with their metaclasses!
>
> 2. allow for either flexible schema, or no schema, a la
> everything's a triple;
Bingo. No schema. Reading must be more intelligent so both reading and
writing become easier. Schemas breed brittleness.
>
> 3. distributed across servers; servers can "attach/detach"
> to db network without pain.
>
> 4. redundant; fault-tolerant; auto-failover;
>
> 5. saves historical data, doesn't overwrite it;
>
> 6. as responsive as traditional relational systems;
>
> 7. does not require centralized write server;
>
> 8. db designed to morph from version to version, not
> require agonizing re-writes like some rdbms require
> <cough>sql svr</cough>.
Boy, you want it all, don't you?
>
> RDF addresses only a small subset of those issues.
> Google's BigTable shows more promise, IMNSHO.
I'll check it out. Love the studly caps, tho.
> The thing that bumps RDBMSs off that pedestal
> will be bold, and will make business sense.
> Migrating dbs is painful and wont be done unless
> there's a large number of advantages over the
> current de facto solutions. I'm not convinced
> RDF running on RAID is it.
Elephant 2000? Natural Language Lite?
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton wrote:
>vanekl wrote:
>> Ken Tilton wrote:
snip
>>>
>>> R! D! F!
>>>
>>> ?
>>>
>>>>
>>>> If a standard network layer could be built that works with
>>>> all major Lisps and all major OS platforms, there's no
>>>> reason why noobs cannot try to attack this problem with
>>>> CL. It's not an easy problem, though. CouchDB is having
>>>> efficiency problems. Elephant, as far as I know, has bogged
>>>> down.
Woops, I was thinking of Rucksack here when I used the word Elephant.
snip
>> I think the next step up in persistence is going to have to:
>>
>> 1. make persistence as transparent to the
>> programming language as possible; plays well with objects;
>
>But I think objects are wrong whether they are persistent or not,
>I say throw them out too as long as we have the hood up. They are
>legacy, they failed, off with their metaclasses!
You may be right. Disruptive technologies usually cast aside
some legacy technologies.
The pendulum does seem to be swinging back to looser coupling
between data and the functions that act of it. To wit, there
is a minor revolt going on right now that even the concept of
inheritance is evil, whereas a few years ago that was less than
a murmur. People are certainly searching for better abstractions.
>>
>> 2. allow for either flexible schema, or no schema, a la
>> everything's a triple;
>
>Bingo. No schema. Reading must be more intelligent so both reading
>and writing become easier. Schemas breed brittleness.
Yeah, CL has proven that a clean, uniform underlying structure
can be highly leveraged. Not that this can be applied to any
problem, but this is certainly the most likely starting point.
>>
>> 3. distributed across servers; servers can "attach/detach"
>> to db network without pain.
>>
>> 4. redundant; fault-tolerant; auto-failover;
>>
>> 5. saves historical data, doesn't overwrite it;
>>
>> 6. as responsive as traditional relational systems;
>>
>> 7. does not require centralized write server;
>>
>> 8. db designed to morph from version to version, not
>> require agonizing re-writes like some rdbms require
>> <cough>sql svr</cough>.
>
>Boy, you want it all, don't you?
What's wrong with that? CL has proven programs can be
updated without a lot of pain.
The big players haven't realized that not only can you
release updates that allow the old code to continue
to work, but that their customers are eventually going
to demand it. It's as if they've never heard of a
factory class, or instantiated a sql parser at runtime
before. It's not that hard.
>> RDF addresses only a small subset of those issues.
>> Google's BigTable shows more promise, IMNSHO.
>
>I'll check it out. Love the studly caps, tho.
Javaland actually has a big jump on Lispers here.
They have a project or two that I believe has goals
similar to that of BigTable.
Every time I start going through their project, however,
I get this sudden urge to go take a shower, so I don't
get very far studying it.
>> The thing that bumps RDBMSs off that pedestal
>> will be bold, and will make business sense.
>> Migrating dbs is painful and wont be done unless
>> there's a large number of advantages over the
>> current de facto solutions. I'm not convinced
>> RDF running on RAID is it.
>
>Elephant 2000? Natural Language Lite?
snip
It's just going to take a startup some time to come up with
a clean vision and then do a lot of exploratory programming.
Open source development is probably too fragmented to come
up with a bold, coherent vision. I expect something to come
out of a startup. Doesn't mean the noobs can give it a stab,
though.
Ellison is vulnerable if he stays wedded to conventional
relational systems. A divorce is coming, or he is going to
watch his trophy wife age mighty fast in the near future and
his eyes will be roving.
On Mar 13, 7:55 am, vanekl <·····@acd.net> wrote:
> The pendulum does seem to be swinging back to looser coupling
> between data and the functions that act of it. To wit, there
> is a minor revolt going on right now that even the concept of
> inheritance is evil, whereas a few years ago that was less than
> a murmur. People are certainly searching for better abstractions.
Interesting! Where could I read more about this?
-- Scott
Scott Burson wrote:
> On Mar 13, 7:55 am, vanekl <·····@acd.net> wrote:
>
>> The pendulum does seem to be swinging back to looser coupling
>> between data and the functions that act of it. To wit, there
>> is a minor revolt going on right now that even the concept of
>> inheritance is evil, whereas a few years ago that was less than
>> a murmur. People are certainly searching for better abstractions.
>
> Interesting! Where could I read more about this?
>
> -- Scott
Well, the last place I read it was at,
http://www.berniecode.com/writing/inheritance/
"Inheritance is evil, and must be destroyed"
but if you Google on >>Inheritance is evil<<
you will see several thousand more instances.
On Mar 13, 12:57 pm, vanekl <·····@acd.net> wrote:
> Scott Burson wrote:
> > On Mar 13, 7:55 am, vanekl <·····@acd.net> wrote:
>
> >> The pendulum does seem to be swinging back to looser coupling
> >> between data and the functions that act of it. To wit, there
> >> is a minor revolt going on right now that even the concept of
> >> inheritance is evil, whereas a few years ago that was less than
> >> a murmur. People are certainly searching for better abstractions.
>
> > Interesting! Where could I read more about this?
>
> > -- Scott
>
> Well, the last place I read it was at,http://www.berniecode.com/writing/inheritance/
> "Inheritance is evil, and must be destroyed"
Thanks for the pointer, but it turned out to be less interesting than
I hoped. While the author didn't intend to, he basically explained
why CL beats Java :) His complaint is mostly with _single_
inheritance (as the first poster on his blog page noted). CL has
multiple inheritance (that you would actually want to use, unlike C+
+'s), and if you want to put a function in a slot, you just do it.
That said, I can see why a little support for automated delegation
could be handy in some cases. Hey, here's a thought: a `defclass'
slot option `:delegate-methods' that takes a list of generic function
names and automatically generates the methods to delegate those
operations to the object in that slot. E.g.
(defclass frob ()
((foo :accessor foo :delegate-methods (mumble))
...))
would generate something like
(defmethod mumble ((x frob) &rest stuff)
(apply #'mumble (slot-value x 'foo) stuff))
Heh, this doesn't quite work because the lambda-list might be
incompatible with that of the actual generic function, as the latter
might have more required parameters. (Not to mention that you'd
really prefer not to cons the rest-list -- I don't know if any
implementations are smart enough to elide that given this code.)
I don't see an obvious solution except to insist that the generic
function `mumble' already exist at the time the `defclass' is
processed, so you can go have a look at its lambda-list. (Which, heh,
I don't think there's a portable way to do. Well, all you care about
is the number of required parameters, so you could just try
incrementing that number until the `defmethod' succeeds... hideous,
but effective :)
Well, I'm just musing here. Maybe someone has thought all this
through and there's already an implementation lying around somewhere?
> but if you Google on >>Inheritance is evil<<
> you will see several thousand more instances.
Okay, maybe later...
-- Scott
Scott Burson wrote:
> On Mar 13, 12:57 pm, vanekl <·····@acd.net> wrote:
>
>>Scott Burson wrote:
>>
>>>On Mar 13, 7:55 am, vanekl <·····@acd.net> wrote:
>>
>>>>The pendulum does seem to be swinging back to looser coupling
>>>>between data and the functions that act of it. To wit, there
>>>>is a minor revolt going on right now that even the concept of
>>>>inheritance is evil, whereas a few years ago that was less than
>>>>a murmur. People are certainly searching for better abstractions.
>>
>>>Interesting! Where could I read more about this?
>>
>>>-- Scott
>>
>>Well, the last place I read it was at,http://www.berniecode.com/writing/inheritance/
>>"Inheritance is evil, and must be destroyed"
>
>
> Thanks for the pointer, but it turned out to be less interesting than
> I hoped. While the author didn't intend to, he basically explained
> why CL beats Java :) His complaint is mostly with _single_
> inheritance (as the first poster on his blog page noted).
Right, and I found it astonishing he never mentioned that he was only
whining about single-inheritance.
I thought I was going to be reading about prototypes. I am starting to
wonder if I am not a closet prototype fan.
>... CL has
> multiple inheritance (that you would actually want to use, unlike C+
> +'s), and if you want to put a function in a slot, you just do it.
>
> That said, I can see why a little support for automated delegation
> could be handy in some cases. Hey, here's a thought: a `defclass'
> slot option `:delegate-methods' that takes a list of generic function
> names and automatically generates the methods to delegate those
> operations to the object in that slot. E.g.
>
> (defclass frob ()
> ((foo :accessor foo :delegate-methods (mumble))
> ...))
>
> would generate something like
>
> (defmethod mumble ((x frob) &rest stuff)
> (apply #'mumble (slot-value x 'foo) stuff))
>
> Heh, this doesn't quite work because the lambda-list might be
> incompatible with that of the actual generic function, as the latter
> might have more required parameters. (Not to mention that you'd
> really prefer not to cons the rest-list -- I don't know if any
> implementations are smart enough to elide that given this code.)
>
> I don't see an obvious solution except to insist that the generic
> function `mumble' already exist at the time the `defclass' is
> processed, so you can go have a look at its lambda-list. (Which, heh,
> I don't think there's a portable way to do. Well, all you care about
> is the number of required parameters, so you could just try
> incrementing that number until the `defmethod' succeeds... hideous,
> but effective :)
>
> Well, I'm just musing here. Maybe someone has thought all this
> through and there's already an implementation lying around somewhere?
What if you also handle delegation at the function site by having a
fallback specialization that asks the first object if it has anyone who
can handle the function.
(defmethod destroy-moscow (other reason &key method)
(bif delegate (find-delegate other 'destroy-moscow)
(destroy-moscow delegate reason :method method)
<some useful error>))
A defdelegate macro could write the above if a defgeneric form was the
only parameter, I think. find-delegate would use your new slot initarg
mumble mumble...
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mar 13, 4:41 pm, Ken Tilton <···········@optonline.net> wrote:
> What if you also handle delegation at the function site by having a
> fallback specialization that asks the first object if it has anyone who
> can handle the function.
What use case do you have in mind?
-- Scott
Scott Burson wrote:
> On Mar 13, 4:41 pm, Ken Tilton <···········@optonline.net> wrote:
>
>> What if you also handle delegation at the function site by having a
>> fallback specialization that asks the first object if it has anyone who
>> can handle the function.
>
> What use case do you have in mind?
Well that is what I am asking (unless I miss your drift). The use case
from the cited article was (as you noted) "What do we do when we cannot
use multiple inheritance?!". :) And, yes, delegation is one workaround
for that.
So what I was saying was, given that we *do* have M/I, I really should
not be offering a delegation hack because I always eviscerate the
denizens of this group for robotically supplying solutions to noob
problems without first determining the use case, because when we do so
we usually learn, oh, you don't want delegation, you want M/I, don't
worry, it works like a charm in CLOS.
I would not answer at such length but I am enjoying watching win32 try
to recover from a blue screen of death on my desktop. :)
And I would not have supplied a delegation hack except it is kinda fun
to figure out how to best implement things like that. :)
kenny
Ken wrote:
> Scott Burson wrote:
>> On Mar 13, 4:41 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>> What if you also handle delegation at the function site by having a
>>> fallback specialization that asks the first object if it has anyone who
>>> can handle the function.
>>
>> What use case do you have in mind?
>
> Well that is what I am asking (unless I miss your drift). The use case
> from the cited article was (as you noted) "What do we do when we cannot
> use multiple inheritance?!". :) And, yes, delegation is one workaround
> for that.
No, it's not. It just gives you one more inheritance link in the simple
case.
In more interesting cases, you want to delegate to more than one
"parent" object, and then you have multiple inheritance again.
> And I would not have supplied a delegation hack except it is kinda fun
> to figure out how to best implement things like that. :)
If you want delegation in CLOS, you should either realize that it's
already there at the class level, or implement it from scratch.
Convincing CLOS to use delegation at the base level is too complicated.
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken wrote:
>> Scott Burson wrote:
>>> On Mar 13, 4:41 pm, Ken Tilton <···········@optonline.net> wrote:
>>>
>>>> What if you also handle delegation at the function site by having a
>>>> fallback specialization that asks the first object if it has anyone who
>>>> can handle the function.
>>>
>>> What use case do you have in mind?
>>
>> Well that is what I am asking (unless I miss your drift). The use case
>> from the cited article was (as you noted) "What do we do when we
>> cannot use multiple inheritance?!". :) And, yes, delegation is one
>> workaround for that.
>
> No, it's not. It just gives you one more inheritance link in the simple
> case.
So you are saying, "Yes, it does"? Good programmers keep everything simple.
>
> In more interesting cases,...
No, those would be broken cases, like the famous example that breaks
CLOS class precedence computation. It is no objection to X that one can
contrive an horrific, contorted, nasal demon "interesting" use case to
make X look bad.
> you want to delegate to more than one
> "parent" object, and then you have multiple inheritance again.
Which we just solved with delegation, so where is the problem? My
delegate can have its delegates.
Well, not "mine". Tilton's Theory of M/I is that you pick exactly one
superclass for each orthogonal domain, each superclass being a node in a
singly-inheritant tree sharing no functionality with any other such tree.
If CL voted tomorrow to yank M/I, no problem, all my delegates will
still only need single-inheritance as long as I stick to my real-world
application-programmer sanity-preserving discipline. I create one
delegate for each extra superclass I would have added under M/I and life
is simple.
Another bit of TToMI is not to inherit from a multiply-inheriting class,
however tempting. ie, even if you see that bad boy sitting there with
two parents you are about add to your super list, keep it flat, list the
two individually. The analog here would be the same, don't get greedy,
keep the delegates flat.
One little thing to remember is, jeez, how many defclasses do we have to
code?!
Real-world craftsman have loads of little disciplines like this they use
to make the real-world manageable.
>
>> And I would not have supplied a delegation hack except it is kinda fun
>> to figure out how to best implement things like that. :)
>
> If you want delegation in CLOS, you should either realize that it's
> already there at the class level,...
You may have missed that it was a deliberate exercise in Giving Noobs
What They Want No Matter How Daft. I was in a mood.
> or implement it from scratch.
> Convincing CLOS to use delegation at the base level is too complicated.
Fer the love of God, lighten up, will you? I should drink less when
posting, you should drink more.
kenny
Ken Tilton wrote:
> I thought I was going to be reading about prototypes. I am starting to
> wonder if I am not a closet prototype fan.
Oh no, is this the next thing you're going to promote as something that
everybody should switch to?!?
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>> I thought I was going to be reading about prototypes. I am starting to
>> wonder if I am not a closet prototype fan.
>
> Oh no, is this the next thing you're going to promote as something that
> everybody should switch to?!?
Maybe a return to StudlyCaps?
Scott Burson wrote:
> On Mar 13, 12:57 pm, vanekl <·····@acd.net> wrote:
>> Scott Burson wrote:
>>> On Mar 13, 7:55 am, vanekl <·····@acd.net> wrote:
>>>> The pendulum does seem to be swinging back to looser coupling
>>>> between data and the functions that act of it. To wit, there
>>>> is a minor revolt going on right now that even the concept of
>>>> inheritance is evil, whereas a few years ago that was less than
>>>> a murmur. People are certainly searching for better abstractions.
>>> Interesting! Where could I read more about this?
>>> -- Scott
>> Well, the last place I read it was at,
>> http://www.berniecode.com/writing/inheritance/
>> "Inheritance is evil, and must be destroyed"
>
> Thanks for the pointer, but it turned out to be less interesting than
> I hoped. While the author didn't intend to, he basically explained
> why CL beats Java :) His complaint is mostly with _single_
> inheritance (as the first poster on his blog page noted). CL has
> multiple inheritance (that you would actually want to use, unlike C+
> +'s), and if you want to put a function in a slot, you just do it.
Yep, there are several ways of getting around the author's problem
(mixins, multiple inheritance, interfaces, envelope pattern, delegation,
etc.) and I don't approve of the author's solution. I like his use of
the strategy pattern but he munged the handleEnterFrame function.
He forced it and it has code smell.
I also wasn't trying to suggest that the author had seen the light and
had some great new solution. Nor was I saying that the inheritance problem
manifests in CL. Most people don't use a programming languages that
supports multiple inheritance, and even though this is a lisp forum, I
was alluding to all the programming languages that would be
attaching to the persistence engine that portions of this thread are
discussing. So, sorry to suggest that CL had the same problem that
Bernie is talking about.
> That said, I can see why a little support for automated delegation
> could be handy in some cases. Hey, here's a thought: a `defclass'
> slot option `:delegate-methods' that takes a list of generic function
> names and automatically generates the methods to delegate those
> operations to the object in that slot. E.g.
>
> (defclass frob ()
> ((foo :accessor foo :delegate-methods (mumble))
> ...))
>
> would generate something like
>
> (defmethod mumble ((x frob) &rest stuff)
> (apply #'mumble (slot-value x 'foo) stuff))
>
> Heh, this doesn't quite work because the lambda-list might be
> incompatible with that of the actual generic function, as the latter
> might have more required parameters. (Not to mention that you'd
> really prefer not to cons the rest-list -- I don't know if any
> implementations are smart enough to elide that given this code.)
>
> I don't see an obvious solution except to insist that the generic
> function `mumble' already exist at the time the `defclass' is
> processed, so you can go have a look at its lambda-list.
I don't see why it's unreasonable to insist that 'mumble' exist,
nor do I see why it's unreasonable to expect the mixin to be sent
just the args it expects. You write mixins to match the problem
and the expected data you will be receiving.
I guess I don't see the issue.
> (Which, heh,
> I don't think there's a portable way to do. Well, all you care about
> is the number of required parameters, so you could just try
> incrementing that number until the `defmethod' succeeds... hideous,
> but effective :)
Yeah, you really did say that out loud :)
> Well, I'm just musing here. Maybe someone has thought all this
> through and there's already an implementation lying around somewhere?
>> but if you Google on >>Inheritance is evil<<
>> you will see several thousand more instances.
>
> Okay, maybe later...
>
> -- Scott
On Mar 13, 3:43 pm, vanekl <·····@acd.net> wrote:
> Most people don't use a programming languages that
> supports multiple inheritance, and even though this is a lisp forum, I
> was alluding to all the programming languages that would be
> attaching to the persistence engine that portions of this thread are
> discussing. So, sorry to suggest that CL had the same problem that
> Bernie is talking about.
I didn't take you as suggesting that specifically. But I think it's
interesting that the meme that's circulating seems to be "inheritance
is evil" rather than "single inheritance is evil". Of course, the
problem is, when people think of multiple inheritance they will think
of C++, and in C++, multiple inheritance is also evil :)
> > I don't see an obvious solution except to insist that the generic
> > function `mumble' already exist at the time the `defclass' is
> > processed, so you can go have a look at its lambda-list.
>
> I don't see why it's unreasonable to insist that 'mumble' exist,
Well, it's a little bit out of the spirit of CLOS, which tries to do
things like create the generic function for you if it sees `defmethod'
before `defgeneric'. But I agree, it's not that big a deal.
> > (Which, heh,
> > I don't think there's a portable way to do. Well, all you care about
> > is the number of required parameters, so you could just try
> > incrementing that number until the `defmethod' succeeds... hideous,
> > but effective :)
>
> Yeah, you really did say that out loud :)
Yep :)
Maybe Closer-to-MOP has a quasi-portable interface for getting the
lambda-list of a generic function.
-- Scott
Scott Burson <········@gmail.com> writes:
> On Mar 13, 12:57 pm, vanekl <·····@acd.net> wrote:
>> Well, the last place I read it was at,http://www.berniecode.com/writing/inheritance/
>> "Inheritance is evil, and must be destroyed"
>
> Thanks for the pointer, but it turned out to be less interesting than
> I hoped. While the author didn't intend to, he basically explained
> why CL beats Java :)
And he does this consistently: http://www.berniecode.com/writing/eval.html
--
__Pascal Bourguignon__
Sometimes the reinventing happens because one is not satisfied with
current solutions... though my framework is a bad (and I mean *really*
bad) clone of weblocks, when I first started working on it I didn't
know about weblocks, and later it was too fun to code for me to stop.
BTW, I had thought about integrating Cells in the framework, but never
did it due to more urgent things to do (like, solving macroscopic bugs
and getting it to be minimally usable!). I might do it sooner or
later ;)
But granted, my framework is not a Real Application :) I'd work on
real applications if someone paid me to do so... unfortunately, while
Lisp's market share is tiny everywhere, I fear in Italy it's
nonexistent :( so I have to stick to Java and C#... what a cruel
world! :)
On 12 Mar, 18:21, Ken Tilton <···········@optonline.net> wrote:
>
> Normally we prefer noobs to reinvent an entire Lisp from scratch,
> failing that to do a dataflow hack like Cells... oh, OK, I think we can
> add web frameworks to the list of approved noob wheel reinventions, we
> already have a lot of those. As long as we have the hood up...
>
> Any other reinventions we should add? Ah, yes, bindings to Gtk or Tk or
> anything OpenGL related, can't have enough of those. And binding
> /generators/ are popular, I know of three, no, four....
>
> Am I going about this wrong? Should we take something nice and stable
> and substandardized and get the noobs to work on confusing things?
>
> Anyone up for a CFFI-alike? A third defsystem to go with ASDF and
> mk:defsystem?
>
> hth, kenny
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
-------
Mister Preacher, tell me what is right
Send the double figures son, you'll see the light
On Mar 13, 9:55 am, Alessio <·············@gmail.com> wrote:
> Sometimes the reinventing happens because one is not satisfied with
> current solutions... though my framework is a bad (and I mean *really*
> bad) clone of weblocks, when I first started working on it I didn't
> know about weblocks, and later it was too fun to code for me to stop.
> BTW, I had thought about integrating Cells in the framework, but never
> did it due to more urgent things to do (like, solving macroscopic bugs
> and getting it to be minimally usable!). I might do it sooner or
> later ;)
> But granted, my framework is not a Real Application :) I'd work on
> real applications if someone paid me to do so... unfortunately, while
> Lisp's market share is tiny everywhere, I fear in Italy it's
> nonexistent :( so I have to stick to Java and C#... what a cruel
> world! :)
Reinventing the wheel is sometimes good. You will a learn a lot of
things and have fun lisping
Joel once wrote about the perils of Java school, but we needs a fallow
up about perils of lisp school.
Everybody is feeling great starting from scratch, something a users in
lesser languages wouldn't even dream of, instead of helping in
creating at least one battle ready solution.
So keep having fun building your framework Alessio, and don't worry
about the lisp jobs, who needs a langauge who doesn't have a descent
web framework in a world of Web 2.0 apps.
Oh and you remind me. I hate how weblocks works with types and clos,it
reminds me of Haskell, beside I have a different idea about how the
widget model should be organized.
So I'm starting a new web framework. Prepare lisp world, another
hackbrary(*) is coming.
Slobodan
(*) http://tourdelisp.blogspot.com/2008/01/common-lisp-libraries-victims-of-drive.html
On Mar 12, 2:36 am, Ken Tilton <···········@optonline.net> wrote:
> > One option is to encode the ID of the server that created the session
> > into the user's session ID, and pass that session ID in requests. Then
> > use a hardware load balancer (or software load balancer I guess) that
> > can recognize that value and make sure it always gets directed to the
> > same server.
>
> I gather these deals do not add too the latency?
Probably does add a little, since there has to be some inspection of
the request by the load balancer and you don't get that for free. But
it shouldn't be too significant, especially compared to not doing load
balancing at all. It's never been an issue in my experience.
- Peter
In my experience you use hardware to make users sticky to a server. The
hardware does this by ip or cookie, such as a f5.
This experience is mostly java based.
--
ltyphair