Re: Proposal to change shimbun-rss-build-message-id

[Katsumi Yamaoka <yamaoka@xxxxxxx>]

>>>>> In [emacs-w3m : No.10873] David Engster wrote:
> The function shimbun-rss-build-message-id, which should build a unique
> message-id from an URL and optionally a date, fails for some of my RSS
> groups. This is due to two things:

> * Everything after a '?' in the URL is ignored, which is problematic
>   since some CMS (e.g. Typo3) can generate RSS feeds with URLs like

>   index.php?id=100&item=3124

> * The optional date is not used at all.

> I attached a patch which should fix this.

TSUCHIYA-san wrote in [emacs-w3m:10061] as follows:

(cf. http://news.gmane.org/group/gmane.emacs.w3m/thread=7421)

K> `shimbun-rss-build-message-id' strips things that follow "?"
K> or "#" in a url string when calculating its md5.

T> Things that follow "#" can obviously be stripped.

T> The point is how we treat things that follow "?".  As you know
T> it's the CGI's query part, which often contains a session ID.
T> If it's just a session ID, it will be as follows when having
T> fetched the index page for the first time:

T> <a href="0001?sid=0001">Article 1</a>

T> But it will be the following when fetching the same index page
T> for the second time:

T> <a href="0001?sid=0002">Article 1</a>

T> In that case, stripping the part in question is the only way
T> to generate a unique ID.

K> However, in sb-mainichi.el IDs generated are overlapped
K> because of this.

T> There is no general answer as mentioned above.  The method
T> should be different according to the sites.

So, I implemented the version of `shimbun-rss-build-message-id'
that strips nothing in sb-mainichi.el, and in sb-nytimes.el
afterward.

> Also, I fail to understand the meaning of the doc string for the
> luna-define-generic of shimbun-rss-build-message-id. As far as I see,
> the current implementation can never return nil. Maybe it should just be
> changed to simply say

>   "Build unique message-id from URL and (optionally) DATE, and return it."

I've installed it.  Thanks.