HamWebReader causes "gaps" in group number

Lu Wei

unread,

May 6, 2011, 10:39:13 PM5/6/11

to

I use HamWebReader to get RSS/ATOM feeds to a internal group created
specifically for that purpose, and found the group article number
increases very quickly: There are 437 articles now but the nubmer has
increased to 8549. There are lots of number gaps. How's that happen?

--
Regards,
Lu Wei
PGP key ID: 0x92CCE1EA

Lu Wei

unread,

May 9, 2011, 5:12:11 AM5/9/11

to

Lu Wei wrote on 2011-5-7 10:39:
> I use HamWebReader to get RSS/ATOM feeds to a internal group created
> specifically for that purpose, and found the group article number
> increases very quickly: There are 437 articles now but the nubmer has
> increased to 8549. There are lots of number gaps. How's that happen?
>

I found that the article index number increases even there is no new
feeds.("{webreader1 http://...}Not modified." message returns.)
Guess it works like this: HamWebReader reads the feed, parsed n items,
increase group article number by n for possible storage, then starts
duplicate checking procedure. I think this is a bug, for the article
numbers should not be allocated until there are really new items.

Could anybody see to this and provide a patch?

Wolfgang Jäth

unread,

May 9, 2011, 10:43:57 AM5/9/11

to

Am 09.05.2011 11:12, schrieb Lu Wei:
>> I use HamWebReader to get RSS/ATOM feeds to a internal group created
>> specifically for that purpose, and found the group article number
>> increases very quickly: There are 437 articles now but the nubmer has
>> increased to 8549. There are lots of number gaps. How's that happen?
>>
> I found that the article index number increases even there is no new
> feeds.("{webreader1 http://...}Not modified." message returns.)
> Guess it works like this: HamWebReader reads the feed, parsed n items,
> increase group article number by n for possible storage, then starts
> duplicate checking procedure.

I think so, too.

>I think this is a bug,

I think, 'bug' is a heavy word for something you even can't really say
whether the autor did want this happen or not. And it doesn't harm in
any way, does it? I'd call it a minor flaw at the utmost.

>for the article
> numbers should not be allocated until there are really new items.

It shouldn't maybe; but who knows, which practical constraints were the
reason for it?

> Could anybody see to this and provide a patch?

I'm afraid, you have to live with it; the last developement of HPG
occured in 2006.

Wolfgang
--

Lu Wei

unread,

May 10, 2011, 8:41:06 AM5/10/11

to

Wolfgang Jäth wrote on 2011-5-9 22:43:
>
>> I think this is a bug,
>
> I think, 'bug' is a heavy word for something you even can't really say
> whether the autor did want this happen or not. And it doesn't harm in
> any way, does it? I'd call it a minor flaw at the utmost.
>

Yes, I take my words back.

>> for the article
>> numbers should not be allocated until there are really new items.
>
> It shouldn't maybe; but who knows, which practical constraints were the
> reason for it?
>
>> Could anybody see to this and provide a patch?
>
> I'm afraid, you have to live with it; the last developement of HPG
> occured in 2006.

Sad fact. Were I have time to learn all those programming stuff, I could
help. I wonder whether it would be better if the project is hosted on
sourceforge or google code.

Wolfgang Jäth

unread,

May 12, 2011, 2:56:33 AM5/12/11

to

Am 10.05.2011 14:41, schrieb Lu Wei:
>
>>> Could anybody see to this and provide a patch?
>>
>> I'm afraid, you have to live with it; the last developement of HPG
>> occured in 2006.
> Sad fact. Were I have time to learn all those programming stuff, I could
> help. I wonder whether it would be better if the project is hosted on
> sourceforge or google code.

Well, the sources are open; so you can modify them anytime if you want.

But I don't think, sourceforge or simillar could give you more chances
of finding an author, than you have here.

Wolfgang
--