Hi,
I just gave portableaserve a shot under ACL. To my suprise, it didn't
work. I do understand if that's because of the :case-sensitive-lower
issue, but it seemed to be more than that. If indeed portableaserve
does not build easily under ACL, I would strongly suggest that it do so
(i.e. build from INSTALL.lisp). Given that aserve does, this should be
the easiest one to build. As far as the compatibility stuff goes, you
can acl-mp a nickname for the mp package, etc.
dave
Dave Bakhash wrote:
> Hi,
>
> I just gave portableaserve a shot under ACL. To my suprise, it didn't
> work. I do understand if that's because of the :case-sensitive-lower
> issue, but it seemed to be more than that. If indeed portableaserve
> does not build easily under ACL, I would strongly suggest that it do so
> (i.e. build from INSTALL.lisp). Given that aserve does, this should be
> the easiest one to build. As far as the compatibility stuff goes, you
> can acl-mp a nickname for the mp package, etc.
Well - there is no reason to use Portableaserve for ACL since there is
already AllegroServe. We do not explicitely ensure that Portableaserve runs
on ACL out of the box. One thing you investigated was the ACL-MP package.
This is a problem with the ACL compatibility layer which cannot use the
packagename MP on some implementations (like LW). Is there really a demand
that portableaserve (instead of allegroserve) runs out of the box on ACL? I
always thought AllegroServe came with all ACL distributions?
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes:
> > I just gave portableaserve a shot under ACL. To my suprise, it
> > didn't work. I do understand if that's because of the
> > :case-sensitive-lower issue, but it seemed to be more than that. If
> > indeed portableaserve does not build easily under ACL, I would
> > strongly suggest that it do so (i.e. build from INSTALL.lisp).
> > Given that aserve does, this should be the easiest one to build. As
> > far as the compatibility stuff goes, you can acl-mp a nickname for
> > the mp package, etc.
>
> Well - there is no reason to use Portableaserve for ACL since there is
> already AllegroServe. We do not explicitely ensure that Portableaserve
> runs on ACL out of the box. One thing you investigated was the ACL-MP
> package. This is a problem with the ACL compatibility layer which
> cannot use the packagename MP on some implementations (like LW). Is
> there really a demand that portableaserve (instead of allegroserve)
> runs out of the box on ACL? I always thought AllegroServe came with
> all ACL distributions?
I think you missed my point. Of *course* AllegroServe works on ACL.
But the whole point of a ``Portable AllegroServe'' is exactly that --
that it be portable. Over time, you must expect that portableaserve
will grow alongside idiosyncrasies that make it continually converge and
diverge towards and away from AllegroServe. But by its name, and its
origin, I would assume, and even insist, that it include ACL as one of
its targets. If I knew that there were this webserver that was portable
among the Lisps, then I'd use it over the specialized version -- even if
I happened to be on the right platform for the specialized one.
There are many reasons to try to make portableaserve work under ACL:
1) it should be the most straightforward of all the implementations
2) it should be a baseline that you're starting from AllegroServe, and
if compatible with ACL, then it could easily be compared with the
performance of AllegroServe
3) PORTABLEaserver implies portability, and so naturally ACL would be a
healthy and obvious target for a webserver (especially in this case,
given the origins)
4) if portableaserve worked on ACL, then it would give at least some
people using ACL a reason to use it instead of AllegroServe, in
which case you increase your install base (and, given the types of
users), probably the support base as well.
Just food for thought.
dave
In article <···············@nerd-xing.mit.edu>, Dave Bakhash wrote:
[ cliped stuff ]
>
>
> I think you missed my point. Of *course* AllegroServe works on ACL.
> But the whole point of a ``Portable AllegroServe'' is exactly that --
> that it be portable. Over time, you must expect that portableaserve
> will grow alongside idiosyncrasies that make it continually converge and
> diverge towards and away from AllegroServe. But by its name, and its
> origin, I would assume, and even insist, that it include ACL as one of
> its targets. If I knew that there were this webserver that was portable
> among the Lisps, then I'd use it over the specialized version -- even if
> I happened to be on the right platform for the specialized one.
First of all you have no right to insist about anything when you do
not pay for it.
On to your main 'point', the fact that portable alegroserve does not
work on acl and this is some how unjust and offends you in some odd
and unique way. Who cares, if it is so important to you to have this
functionality please add it. It seems that you are the only one who
seems to need this so go for it. It looks like a complete wast of
time, but what the hey knock yourself out. Feel free to do this,
for the good of the collective of course.
>
> There are many reasons to try to make portableaserve work under ACL:
these reasons are flawed
>
> 1) it should be the most straightforward of all the implementations
Why? I feel that it would be a complete waste of time because there
is absolutely no need for it to be done. And it would impose a
maintenence load for another platform. There is alegroserve and it
is designed to work with ACL.
> 2) it should be a baseline that you're starting from AllegroServe, and
> if compatible with ACL, then it could easily be compared with the
> performance of AllegroServe
I would be very suprised if alegroserve did not beat portable alegroserve
when using ACL. It was designed to work well with ACL after all.
> 3) PORTABLEaserver implies portability, and so naturally ACL would be a
> healthy and obvious target for a webserver (especially in this case,
> given the origins)
You have it already in alegroserve, so why bother?
> 4) if portableaserve worked on ACL, then it would give at least some
> people using ACL a reason to use it instead of AllegroServe, in
> which case you increase your install base (and, given the types of
> users), probably the support base as well.
why? If I had the licence/support for acl I would use alegroserve.
A real simple reason is that I have 1 vendor to deal with, not 2,
so there are absolutly no chance of punting problems back and
forth.
In closing you have not presented a good reason for anyone to do
the work nessary to make what you want happen, so why should
anyone bother?
marc
>
> Just food for thought.
>
> dave
····@oscar.eng.cv.net (Marc Spitzer) writes:
> In article <···············@nerd-xing.mit.edu>, Dave Bakhash wrote:
> > I think you missed my point. Of *course* AllegroServe works on ACL.
> > But the whole point of a ``Portable AllegroServe'' is exactly that --
> > that it be portable. Over time, you must expect that portableaserve
> > will grow alongside idiosyncrasies that make it continually converge and
> > diverge towards and away from AllegroServe. But by its name, and its
> > origin, I would assume, and even insist, that it include ACL as one of
> > its targets. If I knew that there were this webserver that was portable
> > among the Lisps, then I'd use it over the specialized version -- even if
> > I happened to be on the right platform for the specialized one.
>
> First of all you have no right to insist about anything when you do
> not pay for it.
I think that this attitude is a little brusque. Payment is not the
only right-granting action; arguments from established standards or
the like probably have enough weight that insistence isn't too strong
an attitude.
That said, one can have valid arguments about software, free and
commercial, and yet not see them implemented; time is always in short
supply. I would agree with Marc's suggestion to Mr Bakash that,
should he feel strongly about this issue, a patch to PAserve would
probably be welcome. Also, bug reports are of great use to software
developers, for two reasons; it alerts them of problems and it makes
them feel loved.
[ Dave: ]
> > Just food for thought.
Generally, free software developers have enough food for thought to be
going on with without contributions of dubious ideological and
practical merit. Food for food would probably be more welcome :-)
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
From: Tim Bradshaw
Subject: Re: portableaserve not ACL-compatible?
Date:
Message-ID: <ey3fzxkpgg3.fsf@cley.com>
* Marc Spitzer wrote:
> Why? I feel that it would be a complete waste of time because there
> is absolutely no need for it to be done. And it would impose a
> maintenence load for another platform. There is alegroserve and it
> is designed to work with ACL.
This (and the remaining arguments) are pretty dumb. Imagine I'm
maintaining an application which I want to run on several
implementations. If I have to use portableaserve on all but one and
allegroserve on the remaining one, then I firstly have to do a bunch
of work to cope with that - conditionalising code and/or build
environment. I have to keep up with two libraries instead of one, so
I have to test more, and I have to worry about different bugs and so
on. Finally if portableaserve and allegroserve ever diverge then I
have some really exciting problems. One library is just *much* less
work.
Yes, having portableaserve run on another platform would impose a load
on its maintainers, but this is the correct tradeoff - a few people
might need to do a bit more work in order to let many people do less.
(And yes, I know it's free software, and I take your point about
whining - I've made it often enough myself. If I used portableaserve
and needed to target Allegro I'd help make it work there, and I
encourage other people who do need this to do that. I'm just trying
to point out that there are a lot of good reasons for it to run on
Allegro.)
--tim
In article <···············@cley.com>, Tim Bradshaw wrote:
> * Marc Spitzer wrote:
>
>> Why? I feel that it would be a complete waste of time because there
>> is absolutely no need for it to be done. And it would impose a
>> maintenence load for another platform. There is alegroserve and it
>> is designed to work with ACL.
>
> This (and the remaining arguments) are pretty dumb. Imagine I'm
> maintaining an application which I want to run on several
> implementations. If I have to use portableaserve on all but one and
> allegroserve on the remaining one, then I firstly have to do a bunch
> of work to cope with that - conditionalising code and/or build
> environment. I have to keep up with two libraries instead of one, so
> I have to test more, and I have to worry about different bugs and so
> on. Finally if portableaserve and allegroserve ever diverge then I
> have some really exciting problems. One library is just *much* less
> work.
you are right, I should know better then to post that late at night.
>
> Yes, having portableaserve run on another platform would impose a load
> on its maintainers, but this is the correct tradeoff - a few people
> might need to do a bit more work in order to let many people do less.
>
> (And yes, I know it's free software, and I take your point about
> whining - I've made it often enough myself. If I used portableaserve
> and needed to target Allegro I'd help make it work there, and I
> encourage other people who do need this to do that. I'm just trying
> to point out that there are a lot of good reasons for it to run on
> Allegro.)
>
In all honesty the whining was not the trigger but the demanding.
I use a lot of peoples donated work and I try to be gracious about
it because that is the decent thing to do. It is one way to say
thanks. Now I have said to people I could use this if it had
feature 'whatever' or I wish it had 'whatever' and sometimes I
get lucky. But to demand more stuff from some one or some group
that has already donated his time and produced something is just
really abusive of the producer. And in the long run this makes
them produce less for public consumption. So I guess it all
comes down to self interest.
marc
> --tim
>
>
Tim Bradshaw wrote:
> * Marc Spitzer wrote:
>
>> Why? I feel that it would be a complete waste of time because there
>> is absolutely no need for it to be done. And it would impose a
>> maintenence load for another platform. There is alegroserve and it
>> is designed to work with ACL.
>
> This (and the remaining arguments) are pretty dumb. Imagine I'm
> maintaining an application which I want to run on several
> implementations. If I have to use portableaserve on all but one and
> allegroserve on the remaining one, then I firstly have to do a bunch
> of work to cope with that - conditionalising code and/or build
> environment. I have to keep up with two libraries instead of one, so
> I have to test more, and I have to worry about different bugs and so
> on. Finally if portableaserve and allegroserve ever diverge then I
> have some really exciting problems. One library is just *much* less
> work.
I answered questions about portableaserve and allegroserve diverging in the
other thread. Regarding the problem you outline: The APIs of Portableaserve
and AllegroServe do not differ. AllegroServe is more complete - so not all
software which runs on AllegroServe would run on Portableaserve. For the
software which would run on both systems conditionalising would not be more
than one line (loading it up). So I don't think that this is much of a
burden.
> Yes, having portableaserve run on another platform would impose a load
> on its maintainers, but this is the correct tradeoff - a few people
> might need to do a bit more work in order to let many people do less.
Hehe - yes - But those peoople who maintain it mainly do this to get their
own work done. Actually we are by ourselves users of it - why should we be
responsible to reduce load from those users who do not want to contribute?
Don't get me wrong this does not mean that we only do things we personally
need - critique is always welcome and there is _no_ reason why we should
deny to fix something broken. Of course it will happen sooner when patches
are attached to the critique... ;-)
> (And yes, I know it's free software, and I take your point about
> whining - I've made it often enough myself. If I used portableaserve
> and needed to target Allegro I'd help make it work there, and I
> encourage other people who do need this to do that. I'm just trying
> to point out that there are a lot of good reasons for it to run on
> Allegro.)
Of course - I think too that it _should_ run on ACL out of the box. But I
think it is more a aestethical point than a practical one. AllegroServe is
more feature complete than PortableAserve and it comes as a readily
loadable module with all AllegroCL distributions. There is no real
difference in use for projects which make only use of the common
featureset. (And portableaserve so far has no features not available in
AllegroServe).
ciao,
Jochen
--
http://www.dataheaven.de
From: Tim Bradshaw
Subject: Re: portableaserve not ACL-compatible?
Date:
Message-ID: <ey3r8h4cakw.fsf@cley.com>
* Jochen Schmidt wrote:
> Hehe - yes - But those peoople who maintain it mainly do this to get their
> own work done. Actually we are by ourselves users of it - why should we be
> responsible to reduce load from those users who do not want to contribute?
In case there is confusion: I don't think you should be expected to do
this, and I didn't mean to imply that you should. I think that in the
abstract it would be good if it ran on ACL, but I also think that it's
in the nature of free software that if I want it to do something it
does not do I should be willing to volunteer effort (or funding). I
was just arguing against the position that it's not a good thing to
have, all other things being equal (which they are not).
(so I think, we agree. I'm just nervous of being seen as someone who
expects something for nothing, hence this article...)
--tim
Tim Bradshaw <···@cley.com> writes:
> (so I think, we agree. I'm just nervous of being seen as someone who
> expects something for nothing, hence this article...)
Don't worry. If anyone thinks this, it's Marc Spitzer, and he's already
shown us all that he thrashes from one extreme of hostility and
negative, insulting assumptions to another.
No one in his right mind goes around telling volunteer open-source
developers to do this and that. They can insist on how things ought to
be done, if "done right". Mark Spitzer just wanted someone/something to
attack, and that's what he did, and then recanted, saying:
"you are right, I should know better then to post that late at night."
The last thing that people should worry about when presenting
interesting and fair arguments is being cataloged as freeloaders.
dave
In article <···············@no-knife.mit.edu>, Dave Bakhash wrote:
> Tim Bradshaw <···@cley.com> writes:
>
>> (so I think, we agree. I'm just nervous of being seen as someone who
>> expects something for nothing, hence this article...)
>
> Don't worry. If anyone thinks this, it's Marc Spitzer, and he's already
> shown us all that he thrashes from one extreme of hostility and
> negative, insulting assumptions to another.
The word that set me off was "insist" posted by you dave in message
<···············@nerd-xing.mit.edu>, the definition that applied to it
was "To demand or assert persistently". And te definition of demand
that I took from the context of the message was "To claim as just or
due". There is another definition of demand that was in hindsight at
least as plausable "To need or require as useful, just, proper, or
nessary". Unfortunately it just did not occur to me at the time.
Now Dave why would you attack me by saying I am thinking Tim is a bad
person. That is fucked up Dave and incorrect. If I have an issue
with somebody I will say it, no help needed from concerned
bystanders. After all Dave I never personally attacked you I attacked
what you wrote. You are here and now personally attacking me. Well
Dave it looks to me like you are a bad person after all, please fuck
off now.
>
> No one in his right mind goes around telling volunteer open-source
> developers to do this and that. They can insist on how things ought to
> be done, if "done right". Mark Spitzer just wanted someone/something to
> attack, and that's what he did, and then recanted, saying:
>
First of all just because they can insist, does not mean they should.
And by insisting you just may irratate the developer(s) enough that
they stop or at least stop sharing there work, the same thing from my
POV as a consumer, and this would be bad.
And yes I admited I was wrong as soon as I was given some reason to
believe I was wrong, a very hostile act if ever I saw one.
> "you are right, I should know better then to post that late at night."
>
> The last thing that people should worry about when presenting
> interesting and fair arguments is being cataloged as freeloaders.
Why? In all honestly if 2 people submit the exact same idea to a
given community and one is thought of as a valued member of the
community and the other is believed to be a parasite who will get
their idea treated with respect and who will get ignored?
marc
>
> dave
From: Tim Bradshaw
Subject: Re: portableaserve not ACL-compatible?
Date:
Message-ID: <ey3d6sjdtw6.fsf@cley.com>
* Marc Spitzer wrote:
> Now Dave why would you attack me by saying I am thinking Tim is a bad
> person.
Oh, I'm a very bad person. I have horns on my head, cloven feet,
horrid goat eyes and everything, and I smell strongly of brimstone.
On the internet, no-one knows you're the Devil.
--tim
In article <···············@cley.com>, Tim Bradshaw wrote:
> * Marc Spitzer wrote:
>> Now Dave why would you attack me by saying I am thinking Tim is a bad
>> person.
>
> Oh, I'm a very bad person. I have horns on my head, cloven feet,
> horrid goat eyes and everything, and I smell strongly of brimstone.
>
> On the internet, no-one knows you're the Devil.
>
> --tim
>
True as that may be, it is besides the point. Besides us bad people
have to stick together. Well if you are going to personify the devil
could you do the Elizabeth Hurley version?
marc
From: Tim Bradshaw
Subject: Re: portableaserve not ACL-compatible?
Date:
Message-ID: <ey3ofc2u392.fsf@cley.com>
* Marc Spitzer wrote:
> Well if you are going to personify the devil
> could you do the Elizabeth Hurley version?
Sorry, union regulations won't allow it ... more'n my job's worth ...
booked up for the next three years ... may be able to give you an
appointment in 2005 ... they don't make them like that any more
... fings ain't what they used to be ... cor lummy ... mutter mumble
--tim
Dave Bakhash wrote:
> Tim Bradshaw <···@cley.com> writes:
>
>> (so I think, we agree. I'm just nervous of being seen as someone who
>> expects something for nothing, hence this article...)
>
> Don't worry. If anyone thinks this, it's Marc Spitzer, and he's already
> shown us all that he thrashes from one extreme of hostility and
> negative, insulting assumptions to another.
>
> No one in his right mind goes around telling volunteer open-source
> developers to do this and that. They can insist on how things ought to
> be done, if "done right". Mark Spitzer just wanted someone/something to
> attack, and that's what he did, and then recanted, saying:
>
> "you are right, I should know better then to post that late at night."
>
> The last thing that people should worry about when presenting
> interesting and fair arguments is being cataloged as freeloaders.
Of course - and we are very interested in any feedback on the project.
The only thing that disturbed me a bit with the first message was the
"strongly suggest". I'm no native English speaker but it came over a bit
like a command. But I think it should be clear now that your intention was
simply constructive critique.
ciao,
Jochen
--
http://www.dataheaven.de
····@oscar.eng.cv.net (Marc Spitzer) writes:
> First of all you have no right to insist about anything when you do
> not pay for it.
by "insist", I meant that I would insist that making it work under ACL
is in the best interest of the project.
By no means, of course, was I insisting that it do so and that others do
this. when I want something done (by others) I do it under contract,
and pay for it.
I love the work that has been done by portableaserve, and use it hapily
unde LispWorks.
dave
Dave Bakhash wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> > I just gave portableaserve a shot under ACL. To my suprise, it
>> > didn't work. I do understand if that's because of the
>> > :case-sensitive-lower issue, but it seemed to be more than that. If
>> > indeed portableaserve does not build easily under ACL, I would
>> > strongly suggest that it do so (i.e. build from INSTALL.lisp).
>> > Given that aserve does, this should be the easiest one to build. As
>> > far as the compatibility stuff goes, you can acl-mp a nickname for
>> > the mp package, etc.
>>
>> Well - there is no reason to use Portableaserve for ACL since there is
>> already AllegroServe. We do not explicitely ensure that Portableaserve
>> runs on ACL out of the box. One thing you investigated was the ACL-MP
>> package. This is a problem with the ACL compatibility layer which
>> cannot use the packagename MP on some implementations (like LW). Is
>> there really a demand that portableaserve (instead of allegroserve)
>> runs out of the box on ACL? I always thought AllegroServe came with
>> all ACL distributions?
>
>
> I think you missed my point. Of *course* AllegroServe works on ACL.
> But the whole point of a ``Portable AllegroServe'' is exactly that --
> that it be portable. Over time, you must expect that portableaserve
> will grow alongside idiosyncrasies that make it continually converge and
> diverge towards and away from AllegroServe. But by its name, and its
> origin, I would assume, and even insist, that it include ACL as one of
> its targets. If I knew that there were this webserver that was portable
> among the Lisps, then I'd use it over the specialized version -- even if
> I happened to be on the right platform for the specialized one.
Well - I think "Portable" does not imply "Portable to all lispsystems" but
at least "portable to more than one". PAserve runs on 4 platforms so I
think the name is valid chosen if that matters.
I'm not sure if this was your intention but your article here in c.l.l
(instead of the public discussion forums of portableaserve itself) looks a
bit offensive to my non-native englisch reading eyes. It reads a bit as if
we have done something bad to you and now owe you something.
To the point of diverging codebases. Actually the opposite was true in the
past. The two codebases more and more grew together while ACL-COMPAT
handled more and more ACL stuff. Today there are only minor differences
between the two codebases. The maintainers of AllegroServe and those of
Portable AServe are in contact to talk about additions and changes. All
seem to agree that there is no reason to let the code bases diverge.
You are right on the point that it would be the right thing (tm) when
PAserve would support ACL out of the box too. The reason this is not so is
not because there probably are any conceptual problems but simply the fact
that nobody cared until now. We are no vendor who offers Portable AServe
commercially but it would be of course be possible to pay us to direct the
development in a special direction. If that is not acceptable for one - the
sources are publicly available and patches are always welcome.
All maintainers of a particular port got CVS access to the sourceforge
project and if you want to offer your help to fix this you can get access
too making you the maintainer of the ACL-port of portableaserve.
> There are many reasons to try to make portableaserve work under ACL:
>
> 1) it should be the most straightforward of all the implementations
When coming from AllegroServe - yes - with applied patches it will make need
some minor things. Porting AllegroServe mainly happens by hacking
ACL-COMPAT. We try to reduce the changes in the original sources to a
minimum.
> 2) it should be a baseline that you're starting from AllegroServe, and
> if compatible with ACL, then it could easily be compared with the
> performance of AllegroServe
Maybe but not necessarily.
> 3) PORTABLEaserver implies portability, and so naturally ACL would be a
> healthy and obvious target for a webserver (especially in this case,
> given the origins)
Well ... yes...
> 4) if portableaserve worked on ACL, then it would give at least some
> people using ACL a reason to use it instead of AllegroServe, in
> which case you increase your install base (and, given the types of
> users), probably the support base as well.
We do not compete with AllegroServe.
Actually I personally think that ACL people should use AllegroServe - which
already comes with their lisp-system. The only difference for software
which would run on both is the way you load it which will be no more than
one line of conditionalized code.
> Just food for thought.
Ok
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes:
> We do not compete with AllegroServe.
This is not about competition in that sense. As long as portableaserve
does not run on ACL, it explicitly does not complete directly with
AllegroServe under ACL.
The reason for this thread now is that there's a simple
misunderstanding. The original portableaserve goal was to provide an
application that would perform as closely as possible to AllegroServe on
other platforms. I don't think that this goal will last forever, as the
PAserve project matures. In its maturity, it will only stand to gain as
being a *superior* webserver. For example, suppose (theoretically) that
Franz goes out of business, and no longer supports Aserve. Would
PAserve just stop striving to add new features that address the issues
that arise over time? In my opinion, it's inevitable that
portableaserve should and will support ACL. I'm saying this, despite
not being myself an ACL user.
> Actually I personally think that ACL people should use AllegroServe -
> which already comes with their lisp-system. The only difference for
> software which would run on both is the way you load it which will be
> no more than one line of conditionalized code.
By running PAserve and Aserve on ACL, you can most easily see (through
profiling) where PAserve takes its biggest performance hit. As it is
now, there's no way to compare the two with all other things constant
(AFAIK). One of the main selling points of a webserver is its
performance. If not only for diagnostic reasons, having PAserver on ACL
would be a good thing.
dave
Dave Bakhash wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> We do not compete with AllegroServe.
>
> This is not about competition in that sense. As long as portableaserve
> does not run on ACL, it explicitly does not complete directly with
> AllegroServe under ACL.
>
> The reason for this thread now is that there's a simple
> misunderstanding. The original portableaserve goal was to provide an
> application that would perform as closely as possible to AllegroServe on
> other platforms. I don't think that this goal will last forever, as the
> PAserve project matures. In its maturity, it will only stand to gain as
> being a *superior* webserver. For example, suppose (theoretically) that
> Franz goes out of business, and no longer supports Aserve. Would
> PAserve just stop striving to add new features that address the issues
> that arise over time? In my opinion, it's inevitable that
> portableaserve should and will support ACL. I'm saying this, despite
> not being myself an ACL user.
I agree on this.
>> Actually I personally think that ACL people should use AllegroServe -
>> which already comes with their lisp-system. The only difference for
>> software which would run on both is the way you load it which will be
>> no more than one line of conditionalized code.
>
> By running PAserve and Aserve on ACL, you can most easily see (through
> profiling) where PAserve takes its biggest performance hit. As it is
> now, there's no way to compare the two with all other things constant
> (AFAIK). One of the main selling points of a webserver is its
> performance. If not only for diagnostic reasons, having PAserver on ACL
> would be a good thing.
This is a really good point!
Actually i will look into that issues when I find time next days. I think
the right thing would be to add an "acl" port to ACL-COMPAT which will
probably be not much more than fixing some package issues MP vs. ACL-MP.
In theory ACL should then work.
I have to say that I do not own ACL and do not have the free version
installed here. It would be nice to have someone who could try the fixed
version when it is ready.
ciao,
Jochen
--
http://www.dataheaven.de