| Author |
Message |
< Yaws mailing list ~ Fwd: yaws-1.73 patch for crashmsg |
| Guest |
 Posted: Sat Sep 22, 2007 5:52 pm |
 |
|
|
Guest
|
After I re-read the doc pertaining to process dictionary I started to
have second thoughts about the param vs get/put. I don't think there
is a right or wrong answer here. As I dissected the code I started to
have very bad thoughts about the PD. There are several times where
ARG is massaged... ARG -> ARG2 -> ARG3 and ARG3 is sent to the follow-
up method. On the other hand, there are some instances where a put/
erase combo is used. Also, there are other attributes like 'sc' that
are in the PD.
However, looking at 26K lines of code I really hate the idea of
trolling the code and looking for every instance where this needs to
be repaired. Then I look at the design of the process dictionary and
yaws. If each request is it's own 'single' process then there is no
reason for discarding it.
I think that in the end I'm all about complexity. Keep it simple to
read, debug and extend.... But whether that's with or w/out PD is
debatable and I don't have a real opinion there. Both solutions would
work... However, both are better than having to put hacks in my user
code.
Richard Bucker
richard@bucker.net
Begin forwarded message:
From: "julian@precisium.com" <julian@precisium.com>
Date: September 22, 2007 1:13:21 PM EDT
To: Richard <richard@bucker.net>, Michael FIG
<fig@marketelsystems.com>, Claes Wikstrom <klacke@tail-f.com>
Subject: Re: [Erlyaws-list] yaws-1.73 patch for crashmsg
Well, I'm a little uncomfortable with the use of the process
dictionary at all in this case.
It's probably a convenient shortcut that seems to cut down the arity
of a few functions and could possibly be considered in some sense
'tidy'.. but I think if we're really talking about the 'bigger issue'
here,
we should be looking at what is necessary to ensure includes can nest
properly without unexpected behaviour & interactions.
I suspect that passing state around could be the better approach to
keep contexts truly separate.
As the ARG is part of the API - it may need to be modified by user
supplied modules and also be available for a later custom module in
some sequence
- but that state may not necessarily be carried all the way back to
an earlier caller.
I have my doubts that writing to the process dictionary early in the
request sequence is going to be the right thing at all.
My understanding is that Erlang is very efficient at passing state in
the form of arguments.
Sorry for the rather unspecific comment - my head's not into the
details enough now to say anything more specifically useful.
Cheers,
Julian
Richard wrote:
>
> sorry: handle_ut() not handle_request()
>
> Richard Bucker
> richard@bucker.net <mailto:richard@bucker.net>
>
>
>
> On Sep 22, 2007, at 5:33 AM, Richard wrote:
>
> I think that there is a bigger issue here for (A) as it pertains to
> my original issue and as implemented in this patch. The use of put
> (...), in this case, is inconsistent because in many times it's
> also passed as a parameter. The two uses are conflicting.
>
> The right answer is going to be put(...) in handle_request() and
> removing the params from the various function signatures. Then
> making sure that no other methods are put()'ting/erase()'ing.
>
> **NOTE: while UT and ARG are part of most handle_out_reply(), most
> do not use them. In my case it was passed to ssi().
>
> Richard Bucker
> richard@bucker.net <mailto:richard@bucker.net>
>
>
>
> On Sep 21, 2007, at 10:36 PM, julian@precisium.com
> <mailto:julian@precisium.com> wrote:
>
> Hi,
> Just briefly, I have a couple of concerns with this patch.
>
> a) I think the
> put(yaws_ut, #urltype{}),
> put(yaws_arg, ARG),
>
> would be better placed in yaws_server:handle_out_reply({ssi, File,
> Delimiter, Bindings}, LineNo, YawsFile, UT, ARG)
>
> that way it's consistent with handle_out_reply({ehtml, E}, _LineNo,
> _YawsFile, UT, ARG)
>
> This also allows the actual urltype record to be written instead of
> a blank one.
> Note also the corresponding erase/1 calls.
>
>
> b) yaws_server:ssi/6
> I'm always wary of throwing in extra slashes to make something
> work.. can you please clarify what exactly this is fixing?
> (I'm not clear if it's part of the same crash problem, or two fixes
> in one patch?)
>
> As far as I know Dir (coming from urltype.dir ) should always be
> either an empty string, or have a trailing slash.
>
> I'm not saying what you've done there isn't right, as I haven't had
> a chance to test,
> but the following line now only seems valid for the case where Dir
> is an empty list.. otherwise you'll get two slashes.
>
> construct_fullpath(Docroot, lists:flatten([Dir, [$/|File]]),
>
> I hope to get a chance to look at this further soon.. but in the
> meantime if you could say a few words about the
> situation you're dealing with that requires the extra slash
> (or some sample code to duplicate the issue)
> that would be great.
>
>
> Cheers,
> Julian Noble
>
> Hi,
>
> Thanks for figuring out this stuff, Richard. It helped me find a
> patch to make crashmsg work better.
>
> Below is a patch I needed to have ssi work within a crashmsg
> handler. Please apply it to the latest YAWS.
>
> Thanks,
>
> --
> Michael FIG <fig@marketelsystems.com
> <mailto:fig@marketelsystems.com>>, PMP
> MarkeTel Multi-Line Dialing Systems, Ltd.
> Phone: (306) 359-6893 ext. 528
>
> --- src/yaws_server.erl~ 2007-09-20 07:10:41.000000000 -0600
> +++ src/yaws_server.erl 2007-09-21 14:02:41.000000000 -0600
> @@ -2479,7 +2479,7 @@
> FullPath =
> case File of
> {rel_path, FileName} ->
> - [Docroot, Dir,[$/|FileName]];
> + [Docroot, [$/|Dir],[$/|FileName]];
> {abs_path, FileName} ->
> [Docroot, [$/|FileName]];
> [$/|_] ->
> @@ -2492,7 +2492,7 @@
> %%relative to the Docroot and VirtualDir that
> correspond
> %% to the request.
>
> - construct_fullpath(Docroot, lists:flatten([Dir,
> File]),
> + construct_fullpath(Docroot, lists:flatten([Dir, [$/|
> File]]),
> VirtualDir)
> end,
>
> @@ -2596,6 +2596,8 @@
> ?Debug("handle_crash(~p)~n", [L]),
> SC=get(sc),
> yaws:elog("~s", [L]),
> + put(yaws_ut, #urltype{}),
> + put(yaws_arg, ARG),
> case catch apply(SC#sconf.errormod_crash, crashmsg, [ARG, SC,
> L]) of
> {html, Str} ->
> accumulate_content(Str),
>
>
> ----- Original Message -----
> From: "Richard" <richard@bucker.net <mailto:richard@bucker.net>>
> To: erlyaws-list@lists.sourceforge.net <mailto:erlyaws-
> list@lists.sourceforge.net>
> Sent: Friday, September 21, 2007 9:57:08 AM (GMT-0600) America/
> Guatemala
> Subject: [Erlyaws-list] trying to ehtml_expand({ssi, File, Del,
> Bs}) throws exception
>
> in one of my YAWS files I tried to manually expand an SSI. I tried
> a few different approaches. None worked. The last failed attempt
> was this one. It threw a {badrecord,urltype} exception.
>
>
> <erl>
> out(A) ->
> MyText = yaws_api:ehtml_expand({ssi,"myssifile.ssi","%%",[]}),
> ... some other code...
> .
> </erl>
>
> I believe the exception was generated in yaws_api.erl because get
> (yaws_ut) returned undefined here.
>
> ehtml_expand({ssi,File, Del, Bs}) ->
> UT = get(yaws_ut),
> ARG = get(yaws_arg),
> ... some more code ...
>
>
> I was finally able to make it work like this:
>
> <erl>
> -include("/usr/local/lib/yaws/include/yaws.hrl").
> out(A) ->
> put(yaws_ut,#urltype{}),
> put(yaws_arg,A),
> MyText = yaws_api:ehtml_expand({ssi,"myssifile.ssi","%%",[]}),
> ... some more code ...
>
> My concern is that I'm abusing the framework. There must be a
> better way? Why export the API in yaws_api if:
>
> a) undocumented?
> b) has undocumented requirements
>
> Thanks
>
> Richard
>
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/erlyaws-list
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Sep 23, 2007 8:47 pm |
|
|
|
Guest
|
Ri
> I think that in the end I'm all about complexity. Keep it simple to
> read, debug and extend.... But whether that's with or w/out PD is
> debatable and I don't have a real opinion there. Both solutions would
> work... However, both are better than having to put hacks in my user
> code.
>
In retro perspective, it might have been better to not use the PD to
pass around the #sconf{} record, the #gconf{} record the #url_type{}
record etc since the number of bug we've had over the years related to
the PD have been significant.
I think I once introduced te use of the PD when I realized that I didn't
want to obscure records down through user functions. It's all a trade off
/klacke
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/erlyaws-list
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
