427907 - feed parser returns RSS2 entry guid as property bag

Status: NEW

(Firefox :: General, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

Attachment: testcase demonstrating problem

The feed parser returns the "guid" fields of entries in the RSS2 feed http://weblogs.mozillazine.org/asa/index.rdf as property bags when it should be returning them as simple strings.

For example, for the following entry, item.fields.get("guid") should return "http://weblogs.mozillazine.org/asa/archives/2008/04/pushy.html" but instead returns an nsISupports that is queryable to various nsI*PropertyBag* interfaces.

<item>
<title>pushy</title>
...
<guid>http://weblogs.mozillazine.org/asa/archives/2008/04/pushy.html</guid>
...
</item>

Other properties, like "title", are correctly returned as simple strings.  The returned property bag just contains a single property whose name is "guid" and whose value is the value of the guid, so the correct data is being returned, it is just being returned wrapped in an extraneous property bag.

Here's a testcase that demonstrates the problem.  You need to run it as chrome or enable codebase principals (by setting the preference signed.applets.codebase_principal_support to true) and trust it thrice to run it.

Filed in Browser:General because I can't find a better place for it.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

Callek points out that this test <http://mxr.mozilla.org/mozilla/source/toolkit/components/feeds/test/xml/rss2/item_guid.xml> implies the behavior is intentional, but I can't see why it's beneficial, so perhaps this is a request to enhance the API to return the guid directly.

Comment 2

[Robert Sayre]

This should be available as nsIFeedContainer.id.

http://developer.mozilla.org/en/docs/nsIFeedContainer#Attributes

Comment 3

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #2)
> This should be available as nsIFeedContainer.id.
> 
> http://developer.mozilla.org/en/docs/nsIFeedContainer#Attributes

Yeah, I know about that, but I actually ran into this issue when enumerating fields and then processing each one, so I wasn't specifically retrieving the guid (although I was using it when I found it).

I can understand authors, links, and categories being returned as nsIArrays, given that they can have multiple values (although it's not clear why they are accessible in the same way both as properties on nsIFeedContainer and values in its fields bag--I'd think the latter would be a version closer to the metal).

But guid, like title, can only have a single string value, so what's the benefit to wrapping it in another property bag?

Comment 4

[Robert Sayre]

The fields bag is closer to the metal. The named attributes are normalized, using values from namespaced extensions instead of core elements if necessary. This mixing is not as rare as one might want, so we support it. The bag provides unnormalized access.

I'm not sure why getting access to guid through .fields is important, but I suppose this is a bug in principle.

Comment 5

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #4)
> I'm not sure why getting access to guid through .fields is important, but I
> suppose this is a bug in principle.

It is relevant to a client processing the fields of an entry without regard to the specific meaning of each field, f.e. a client that displays the metadata associated with each entry in a feed, or one that stores the metadata in a persistent datastore that it then makes available to other clients via an API.

Comment 6

[Robert Sayre]

OK, I smell where this is going. I don't think anyone using this API has done replication this intense, so you're going to hit some rough areas. What kind of schedule are you on?

Comment 7

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #6)
> OK, I smell where this is going. I don't think anyone using this API has done
> replication this intense, so you're going to hit some rough areas. What kind of
> schedule are you on?

It's all just experimentation at this point, and I can work around the problem by unwrapping the value, so it's not urgent.