Hi,
I was trying to use the svn branch of Hunchentoot, and found, to my surprise, that most of my old code didn't work anymore. The culprit mainly seems to be request.lisp, where a lot of old functions/methods have been renamed with a * suffixed to their name.
Are these changes permanent? Will these make it into the release version? Also, what is the reason behind this? I tried searching the mailing list for any discussion on this, but couldn't find anything.
One more thing, there were no such changes to reply.lisp i.e. no *-suffixed names there. Will the reply methods also undergo these changes?
Chaitanya
On Sun, Aug 31, 2008 at 07:10, Chaitanya Gupta mail@chaitanyagupta.com wrote:
Hi,
I was trying to use the svn branch of Hunchentoot, and found, to my surprise, that most of my old code didn't work anymore. The culprit mainly seems to be request.lisp, where a lot of old functions/methods have been renamed with a * suffixed to their name.
Are these changes permanent? Will these make it into the release version? Also, what is the reason behind this? I tried searching the mailing list for any discussion on this, but couldn't find anything.
We found that it was very inconvenient that there are no accessor functions for the slots in the request object, and that the accessors should be conventionally named. I think we are not completely done with the API cleanup, though, and it may well be that there will be further changes before the next real release (i.e. the reply class may be changed, too). It is propably safe to assume that the *-versions of the accessors will stay forever.
-Hans
Hans Hübner wrote:
We found that it was very inconvenient that there are no accessor functions for the slots in the request object, and that the accessors should be conventionally named. I think we are not completely done with the API cleanup, though, and it may well be that there will be further changes before the next real release (i.e. the reply class may be changed, too). It is propably safe to assume that the *-versions of the accessors will stay forever.
Ok. But does it mean that code written for the current release version of hunchentoot will break? As of now, I can't really use our existing code with the dev version, which is quite a dampener..
Chaitanya
On Mon, Sep 1, 2008 at 15:08, Chaitanya Gupta mail@chaitanyagupta.com wrote:
Hans Hübner wrote:
We found that it was very inconvenient that there are no accessor functions for the slots in the request object, and that the accessors should be conventionally named. I think we are not completely done with the API cleanup, though, and it may well be that there will be further changes before the next real release (i.e. the reply class may be changed, too). It is propably safe to assume that the *-versions of the accessors will stay forever.
Ok. But does it mean that code written for the current release version of hunchentoot will break? As of now, I can't really use our existing code with the dev version, which is quite a dampener..
Yes. Code for the current release version of Hunchentoot will not be compatible to code for the next release version. You need to either stay with the old release, code for the new release and use the dev version or port forward once the new release is out. The new release is will take several weeks to show up.
-Hans
On Mon, Sep 1, 2008 at 6:57 PM, Hans Hübner hans@huebner.org wrote:
Yes. Code for the current release version of Hunchentoot will not be compatible to code for the next release version. You need to either stay with the old release, code for the new release and use the dev version or port forward once the new release is out. The new release is will take several weeks to show up.
:(
Does it have to break so badly? I don't see the *-suffixed versions giving any real advantage, and the slot accessors can just be renamed to something else -- e.g. request-get-parameters, etc. -- instead of currently exported symbols.
Chaitanya
On Mon, 1 Sep 2008 21:51:20 +0530, "Chaitanya Gupta" mail@chaitanyagupta.com wrote:
Does it have to break so badly?
Yes. Except that I wouldn't call it "break". Generally, I think it is better to introduce several incompatible changes at once than to do it piecemeal with every release.
I don't see the *-suffixed versions giving any real advantage, and the slot accessors can just be renamed to something else -- e.g. request-get-parameters, etc. -- instead of currently exported symbols.
We thought about this as well and eventually decided to go this way. One of the goals of the new release is a clearer CLOS-based model of the request/response phase and we think that the names should reflect this. I'm usually trying to be as backwards-compatible as possible (mind you, I have to update my web apps as well!), but sometimes it simply isn't possible.
As Hans said, if you think the new release doesn't buy you anything, you are free to stick with the previous one. You can even have both for the price of one. (Special offer, will only last until Halloween!)
Cheers, Edi.
On thing that could be done would be to introduce the *'ed symbols into a maintenance release of the old hunchentoot such that calls to say (script-name) in the current codebase can then be (script-name*) which should work with the new regime.
that might help ease the transition. just a thought...
cyrus
On Sep 1, 2008, at 10:59 AM, Edi Weitz wrote:
On Mon, 1 Sep 2008 21:51:20 +0530, "Chaitanya Gupta" <mail@chaitanyagupta.com
wrote:
Does it have to break so badly?
Yes. Except that I wouldn't call it "break". Generally, I think it is better to introduce several incompatible changes at once than to do it piecemeal with every release.
I don't see the *-suffixed versions giving any real advantage, and the slot accessors can just be renamed to something else -- e.g. request-get-parameters, etc. -- instead of currently exported symbols.
We thought about this as well and eventually decided to go this way. One of the goals of the new release is a clearer CLOS-based model of the request/response phase and we think that the names should reflect this. I'm usually trying to be as backwards-compatible as possible (mind you, I have to update my web apps as well!), but sometimes it simply isn't possible.
As Hans said, if you think the new release doesn't buy you anything, you are free to stick with the previous one. You can even have both for the price of one. (Special offer, will only last until Halloween!)
Cheers, Edi. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Edi Weitz wrote:
We thought about this as well and eventually decided to go this way. One of the goals of the new release is a clearer CLOS-based model of the request/response phase and we think that the names should reflect this. I'm usually trying to be as backwards-compatible as possible (mind you, I have to update my web apps as well!), but sometimes it simply isn't possible.
So that's that then, which is fine. I still wish, though, that this didn't have to happen. :)
Still, I can't really see what will be gained by exporting the request(or reply) accessors. If you can explain what you have in mind when you say a clearer CLOS-based model, and how it will help, that will be great.
Cheers, Chaitanya
On Wed, 03 Sep 2008 13:13:24 +0530, Chaitanya Gupta mail@chaitanyagupta.com wrote:
Still, I can't really see what will be gained by exporting the request(or reply) accessors. If you can explain what you have in mind when you say a clearer CLOS-based model, and how it will help, that will be great.
The idea is that all the relevant objects (request, replies, servers) are CLOS objects (which is already the case) and exported (which isn't the case now) so that you can subclass them and write your own methods which override the default behaviour. This is not possible with functions like, say, the current REQUEST-METHOD that only have optional parameters. In the future, REQUEST-METHOD (with a required parameter) will be a generic function while REQUEST-METHOD* (with an optional parameter like now) will just be a "convenience layer", if you so will. We thought about naming the generic function REQUEST-REQUEST-METHOD or something like that, but all the alternatives we came up with sounded dumb. I think it's better to use the "real" names (the ones derived from the RFCs or legacy usage) for the "real" functions.
Edi.
On Wed, Sep 3, 2008 at 09:51, Edi Weitz edi@agharta.de wrote:
The idea is that all the relevant objects (request, replies, servers) are CLOS objects (which is already the case) and exported (which isn't the case now) so that you can subclass them and write your own methods which override the default behaviour.
One example usage for this would be in a web framework that associates certain kinds of information (i.e. sessions, users, uploaded files) with a request earlier in the request processing chain. Currently, this can be done using the aux-request-value mechanism, but that is rather clumsy.
-Hans
Edi Weitz wrote:
The idea is that all the relevant objects (request, replies, servers) are CLOS objects (which is already the case) and exported (which isn't the case now) so that you can subclass them and write your own methods which override the default behaviour. This is not possible with functions like, say, the current REQUEST-METHOD that only have optional parameters. In the future, REQUEST-METHOD (with a required parameter) will be a generic function while REQUEST-METHOD* (with an optional parameter like now) will just be a "convenience layer", if you so will.
That makes things a little clearer. Thanks.
I'll be looking forward to how this turns out.
Cheers, Chaitanya
-
Chaitanya Gupta -
Cyrus Harmon -
Edi Weitz -
Hans Hübner