Re: [slrn-pre0.9.9] storing raw article via read_article_hook does not work anymore
Christian Ebert <[email protected]>
| Newsgroups | gmane.network.slrn.user |
|---|---|
| Organization | Black Trash Productions <http://www.blacktrash.org/> |
| Message-ID | <[email protected]> |
* John E. Davis on Friday, November 23, 2007 at 13:50:08 +0000 > Christian Ebert <[email protected]> wrote: >> While accessing SlrnTools->current_rawart still works from >> /scripts/, it stopped being accessable from read_article_hooks >> registered after the hook above. > > Currently, hooks are called in the reverse order that they were > registered. That is, the most recently registered will get called > first. Ah, like from a stack. And I tried to force the other way round ... > This is consistent with, e.g., the C library atexit > function works. Could this be what you are seeing? Yes. >> Now scripts interpreted after tools.sl have the raw article >> available as SlrnTools->current_rawart even *after* a call to >> replace_article. > > It is unclear to me what you mean. If a read-article-hook "foo" was > registered after hook "bar", then "foo" will get called before "bar". > Suppose that "bar" calls replace_article, and "foo" calls > raw_article_as_string. Then what "foo" sees as the raw article will be > affected by "bar". Is that the issue? Yes. Now that I know that the calling order is reversed I can adapt my workaround. I have to ensure that the hook that stores the raw article is interpreted /last/ not first. > If the order that the hooks are called is the problem, then it seems > to me that the best solution would be to change the replace_article > function so that the original raw article is preserved. Like Jörg I believe that the best and least confusing thing would be if raw_article_as_string did what its name says: get the raw article as string ;-) OTOH one could argue that the current behaviour enforces very strictly that the server is not polled unnecessarily. c -- _B A U S T E L L E N_ lesen! --->> <http://www.blacktrash.org/baustellen.html> ------------------------------------------------------------------------- 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/