Argotic Work Item Rss Feed

Reopened Issue: ITunesSyndicationExtension generater itunes:image tag incorrectly [10626]

Oppositional — Fri, 14 Jun 2013 07:16:04 GMT

The extension ITunesSyndicationExtension generates/write incorrect XML for itunes:image element.

Closed Issue: ITunesSyndicationExtension generater itunes:image tag incorrectly [10626]

Oppositional — Thu, 16 May 2013 09:58:11 GMT

The extension ITunesSyndicationExtension generates/write incorrect XML for itunes:image element.

Created Issue: feed causes StackOverflowException [24277]

madewokherd — Sat, 11 May 2013 21:11:30 GMT

The feed at this url causes a StackOverflowException: https://gdata.youtube.com/feeds/base/users/cakemagic/uploads

Created Issue: Now way to access Etag of a feed for polling [23898]

nisbus — Tue, 12 Feb 2013 10:10:20 GMT

Hi,

I have a feed reader that's polling multiple feeds.
Some of the feeds return an etag header (or a last modified) which would minimize the bandwidth I'm consuming but I can't find a way to access it and use it on subsequent calls to the feed.

How is this done with Argotic?

thanks,
nisbus

Commented Issue: Feed publication dates incorrectly deserialized based on timezone [10940]

jontsao — Fri, 03 Aug 2012 16:18:28 GMT

We are in timezone GMT +0200.
If the feed has the pubdate in GMT +0200 there are now problems and the time is correct.
If the feed has the pubdate in GMT the time we get from argotic(item.PublicationDate) is 2 hours in the past.
If the feed has the pubdate in CEST we get the error datetime.

In the documetnation: AtomEntry.PublishedOn Property
The DateTime should be provided in Coordinated Universal Time (UTC).

When testing:

GMT
1345 http://www.nieuwsblad.be/rss.aspx?section=nieuws&subsection=binnenland
<pubDate>Wed, 06 Aug 2008 07:38:17 GMT</pubDate> => #8/6/2008 7:38:17 AM# => must be #8/6/2008 9:38:17 AM#

+0200
1285 http://www.arena51.be/nl/rss/nl/news.xml
<pubdate>Tue, 05 Aug 2008 22:47:13 +0200</pubdate> => #12:00:00 AM# => error datetime
2246 http://www.zita.be/xml/lifestyle.xml
<pubDate>Wed, 06 Aug 2008 00:02:49 +0200</pubDate> => #8/6/2008 12:02:49 AM# => correct

CEST
2007 http://www.knack.be/feeds/72-nieuws-sport-article-rss2.0.xml
<pubDate>Wed, 06 Aug 2008 08:00:00 CEST</pubDate> => #12:00:00 AM# => error datetime
Comments: ** Comment from web user: jontsao **

The offending code is somewhere in the Rfc822 code. I'm not sure why Argotic is doing pre-parsing/formatting of datetimes itself, rather than just relying on DateTime's built-in vanilla TryParse. What I did to work around this issue is just to replace the TryParseRfc822DateTime method with a simple DateTime.TryParse, and that fixed things for me. It'd be nice if this could be fixed, but it looks like the project has been abandoned.

Commented Issue: CompareTo bug [18405]

JamesCurran — Sat, 30 Jun 2012 01:20:08 GMT

There a serious bug in the pattern used for CompareTo throughout the project. Using (and simplying) GeoCoding as an example, the CompareTo looks like this:

int result = A.Latitude.CompareTo(B.Latitude);
result = result | A.Longitude.CompareTo(B.Longitude);
return result;

This pattern determines that A > B only if every property of A is greater than the corresponding property in B. If any property in A is less than B, than overall A < B.

The problem is that it's not reflexive. For example:
NewYork = {Latitude = 40.716, Longitude = -74.0}
Chicago = {Latitude = 41.836, Longitude = -87.684}

Now, since NewYork.Latitude < Chicago.Latitude then NewYork < Chicago.
However, since Chicago.Longitude < NewYork.Longitude, then Chicago < NewYork
This could lead to an infinite loop if someone tried sorting nodes.

Further, beside fundementally not working, it also has a couple technical problems
- it assumes that CompareTo returns -1, 0, +1 when it's only required to return <0, 0, >0
- it requires that every property be tested, even it it's already decided that they are unequal.

A better pattern would be:

int result = A.Latitude.CompareTo(B.Latitude);
if (result == 0) result =A.Longitude.CompareTo(B.Longitude);
return result;
Comments: ** Comment from web user: JamesCurran **

Sorry about takes so long to reply. I never saw the response notification from CodePlex. So, only a year (and a day) later......

Yes, we need only look at meaningful properties (which for most types of nodes, may only be one property)

Created Issue: Uri with Spaces Causes "Unknown Error (400)" in iTunes 10.5.1 [21855]

boyan — Fri, 02 Dec 2011 01:25:19 GMT

One fix is to modify Argotic.Core/Syndication/Rss/RssEnclosure.cs:
in function

public void WriteTo(XmlWriter writer)

change

writer.WriteAttributeString("url", this.Url != null ? this.Url.ToString() : String.Empty);

to

writer.WriteAttributeString("url", this.Url != null ? HttpUtility.UrlPathEncode(this.Url.ToString()) : String.Empty);

Created Issue: Platform & Implementation dependent (unit test) code ToString, GetHashCode [21058]

Trickster — Fri, 01 Jul 2011 12:11:45 GMT

All ToString methods where XmlWriterSettings class is used will produce different strings on Windows, Mac and Linux (because of different newline sequences)
GetHashCode overrides implemented as this.ToString().GetHashCode() will return (expectedly) different results on different platform implementations (ms .net, mono etc). That is why many GetHashCode unit tests fail.

Commented Issue: CompareTo bug [18405]

Trickster — Tue, 28 Jun 2011 02:06:09 GMT

Ok, let me reformulate my question. Can we use in CompareTo methods only 'meaningful' properties? Just like Latitude and Longitude in GeoCoding case

Commented Issue: CompareTo bug [18405]

JamesCurran — Tue, 28 Jun 2011 01:31:33 GMT

GeoCoding was used just as an example. Every CompareTo throughout the library uses that pattern, and has the same problems. GeoCoding just made for a easy concrete example.

Commented Issue: CompareTo bug [18405]

Trickster — Mon, 27 Jun 2011 22:04:30 GMT

I think we can leave only coordinates comparison. Why we need to compare other properties?

Closed Issue: RFC3339(Atom) Parsing Problems [21035]

Trickster — Mon, 27 Jun 2011 21:11:52 GMT

Please post problem strings in comments
Comments:

Closed Issue: RFC3339(Atom) Parsing Problems [21036]

Trickster — Mon, 27 Jun 2011 21:11:38 GMT

Please post problem strings in comments
Comments:

Created Issue: RFC3339(Atom) Parsing Problems [21036]

Trickster — Mon, 27 Jun 2011 21:11:21 GMT

Please post problem strings in comments

Created Issue: RFC3339(Atom) Parsing Problems [21035]

Trickster — Mon, 27 Jun 2011 21:11:15 GMT

Please post problem strings in comments

Created Issue: RFC3339(Atom) Parsing Problems [21034]

Trickster — Mon, 27 Jun 2011 21:11:12 GMT

Please post problem strings in comments

Created Issue: RFC822(RSS) Parsing problems [21033]

Trickster — Mon, 27 Jun 2011 21:10:11 GMT

Please post problem strings in comments

Closed Issue: Is this project accepting bug fixes? [19577]

Trickster — Mon, 27 Jun 2011 20:41:13 GMT

There is a pretty serious bug in the iTunesSyndicationExtensionContext class. Asking again if this project is still being maintained or accepting bug fixes? I have one if any of the admins here are interested.
Comments:

Commented Issue: Is this project accepting bug fixes? [19577]

Trickster — Mon, 27 Jun 2011 20:41:06 GMT

ok it's already here, so I can close this issue

Commented Issue: Is this project accepting bug fixes? [19577]

Trickster — Mon, 27 Jun 2011 20:36:07 GMT

Thankyou for your code. I'll include this fix in next commit. You can view and submit more patches using this url: http://argotic.codeplex.com/SourceControl/list/patches