Well, it's obvious that if the XML couldn't parse the XML, then it's not valid XML. Add to this the fact that it contains a "meta" tag and it's clear that what's at the other end of the link was actually HTML. If you go to http://www.nytimes.com/rss, you'll notice this yourself.
The real feed can be found by following the browser feed icon in the URL bar. It takes you to what the page describes as a feed in the tag <link rel="alternate" type="application/rss+xml" ... />. If you follow it, you will get to this URL: http://feeds.nytimes.com/nyt/rss/HomePage Try it, it should work. Vassil On Fri, Sep 3, 2010 at 2:35 AM, Imtiaz Ahmed H E <[email protected]> wrote: > I have an action > > every 1 mins rss:http://www.nytimes.com/rss > > feed link got thro' right-click on RSS icon at bottom of nytimes.com and > "copy link location" in windows context menu and paste into esme with rss: > prepended. > > and, > > every 1 mins atom:http://twitter.com/statuses/user_timeline/esjewett.atom > > and I get in the Tomcat Window, > > WARN - Going to buffer response body of large or unknown size. Using > getResponse > BodyAsStream instead is recommended. > :37:31: expected closing tag of meta > <a > href="http://www.nytimes.com/pages/sports/index.html";>Sports< > /a> > ^ > > > and, apparently for the twitter feed, > > WARN - Going to buffer response body of large or unknown size. Using > getResponse > BodyAsStream instead is recommended. > :37:31: expected closing tag of meta > <a > href="http://www.nytimes.com/pages/sports/index.html";>Sports< > /a> > ^ > WARN - Cookie rejected: "$Version=0; k=122.167.31.233.1283470309076286; > $Path=/; > $Domain=.twitter.com". Illegal domain attribute ".twitter.com". Domain of > origi > n: "twitter.com" > WARN - Cookie rejected: "$Version=0; > _twitter_sess=BAh7CDoPY3JlYXRlZF9hdGwrCNq2y > tQqAToHaWQiJWRjMTNkMjQ2ZGRiYjA2%250AOTU1ZGZjMTc1NjMxMTZhN2I4IgpmbGFzaElDOidBY3Rp > b25Db250cm9sbGVy%250AOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA--f65405470eedc4a64 > defa69a0e78d22bd676cc0c; $Path=/; $Domain=.twitter.com". Illegal domain > attribut > e ".twitter.com". Domain of origin: "twitter.com" > > > > No feed updates in Esme. > > Vassil, would you want to fix this or shall I look into it. > > Imtiaz > > ----- Original Message ----- From: "Vassil Dichev" <[email protected]> > To: <[email protected]> > Sent: Friday, September 03, 2010 1:29 AM > Subject: Re: ESME-267 - Pooled links in popular links list > > >> Fixed. Now if you post the same link to a pool and to the public, you >> will notice that the href attribute points to the internal shortened >> URL in the former case and to the target URL in the latter case. This >> means that popularity statistics will only be gathered when links on >> public messages are clicked. >> >> An unique ID is still generated for all URLs but for links in pooled >> messages they're not visible. >> >> This should fix the problem. Does someone want to verify that we have >> indeed the correct behavior? >> >> Vassil >> >> >> On Wed, Sep 1, 2010 at 8:18 AM, Richard Hirsch <[email protected]> >> wrote: >>> >>> Sounds like a god idea. >>> >>> D. >>> >>> On 8/31/10, Vassil Dichev <[email protected]> wrote: >>>> >>>> Right, we just don't generate and store a unique ID for links in pools >>>> and will generate a different object on parsing. This way links which >>>> come from pools will point directly to the target URL and links from >>>> public messages will be redirected through the internal shortened URL, >>>> which will allow statistics to be collected. This won't break any >>>> functionality and I think it could be done fairly easily. >>>> >>>> I will assign ESME-267 to me if nobody objects to the proposed solution. >>>> >>>> Vassil >>>> >>>> >>>> On Tue, Aug 31, 2010 at 9:20 PM, Richard Hirsch <[email protected]> >>>> wrote: >>>>> >>>>> Leave original link but just don't add it to PopularLinks. >>>>> >>>>> On 8/31/10, Ethan Jewett <[email protected]> wrote: >>>>>> >>>>>> Oh, I see. Yes, that would make sense. So we would just leave the >>>>>> original link in there, right? >>>>>> >>>>>> Ethan >>>>>> >>>>>> On Tue, Aug 31, 2010 at 8:12 PM, Richard Hirsch >>>>>> <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> I agree with the solution of just removing those links that originate >>>>>>> in >>>>>>> pools. >>>>>>> >>>>>>> D. >>>>>>> >>>>>>> On 8/31/10, Vassil Dichev <[email protected]> wrote: >>>>>>>> >>>>>>>> OK, I think this is a worse example, because there are many ways to >>>>>>>> find a list of URLs in a wiki (which were generally just not >>>>>>>> designed >>>>>>>> with privacy/security in mind). >>>>>>>> >>>>>>>> If you're willing to sacrifice convenience for security, the easiest >>>>>>>> change is not to parse URLs in messages in pools- it will appear as >>>>>>>> normal text, not as a hyperlink. The next thing we can do is set up >>>>>>>> a >>>>>>>> different type of URL which doesn't take you to the shortened URL, >>>>>>>> but >>>>>>>> directly to the target URL. >>>>>>>> >>>>>>>> If one really insists on shortening URLs in pools, then there must >>>>>>>> be >>>>>>>> one set of shortened URLs per pool. I don't think anyone will claim >>>>>>>> that this idea makes sense. >>>>>>>> >>>>>>>> Vassil >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Aug 31, 2010 at 11:35 AM, Ethan Jewett <[email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I agree in theory with your assessment of the google docs >>>>>>>>> situation, >>>>>>>>> but I still think we're violating the expectation of security >>>>>>>>> around >>>>>>>>> pools. >>>>>>>>> >>>>>>>>> Take another example: An HR department is using a secure wiki to >>>>>>>>> discuss and organize an upcoming layoff. The wiki page is titled >>>>>>>>> "October layoff planning" and the URL is >>>>>>>>> https://hrwiki.corp.internal/October-layoff-planning. Someone posts >>>>>>>>> this URL to the layoff-planning pool on esme (the same group of >>>>>>>>> people >>>>>>>>> with access to the wiki page) and a bunch of people in the pool >>>>>>>>> click >>>>>>>>> on it. Suddenly, the upcoming layoff has been announced to every >>>>>>>>> esme >>>>>>>>> user in the corporation. Whoops! >>>>>>>>> >>>>>>>>> The point is, maybe that private information shouldn't be in the >>>>>>>>> URL, >>>>>>>>> but a lot of applications do this whether or not it is a good idea. >>>>>>>>> I >>>>>>>>> think we need to take that reality into account and change the way >>>>>>>>> this works to avoid the possibility of these scenarios. >>>>>>>>> >>>>>>>>> Ethan >>>>>>>>> >>>>>>>>> On Tuesday, August 31, 2010, Vassil Dichev <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Ethan, this defeats the purpose of having an URL shortener and it >>>>>>>>>> only >>>>>>>>>> gives you a false sense of security. Read my previous mail. >>>>>>>>>> >>>>>>>>>> Links have no notion of a pool. A link could come from messages in >>>>>>>>>> different pools or it might not be clicked "inside a message" at >>>>>>>>>> all. >>>>>>>>>> >>>>>>>>>> Let me know what you think. >>>>>>>>>> >>>>>>>>>> Vassil >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Aug 31, 2010 at 9:44 AM, Ethan Jewett <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> [Changed subject to start a new thread. Was: "New issues - a >>>>>>>>>>> couple >>>>>>>>>>> of >>>>>>>>>>> blockers for 1.1 release"] >>>>>>>>>>> >>>>>>>>>>> That's correct. The "Popular messages" functionality just keeps a >>>>>>>>>>> counter of how many times a message has been resent. If you look >>>>>>>>>>> at >>>>>>>>>>> the UserActor.scala, lines 197 & 198, you'll see that the >>>>>>>>>>> statistic >>>>>>>>>>> "ResendStat" is incremented when a message is resent, but only if >>>>>>>>>>> the >>>>>>>>>>> message is not in a pool. Then when we want to find out what the >>>>>>>>>>> most >>>>>>>>>>> popular messages are, we ask the PopStatsActor - for example in >>>>>>>>>>> the >>>>>>>>>>> "popular" method of UserSnip.scala - line 213. >>>>>>>>>>> >>>>>>>>>>> On the other hand, the "LinkClicked is incremented in >>>>>>>>>>> UrlStore.scala >>>>>>>>>>> - >>>>>>>>>>> line 40. Here there is never a check to see if the link came from >>>>>>>>>>> a >>>>>>>>>>> message in a pool. (This counter is used in the "links" method in >>>>>>>>>>> UserSnip.scala, after the "popular" method.) >>>>>>>>>>> >>>>>>>>>>> I think we need to check if a link came from a pool before >>>>>>>>>>> incrementing the counter, but in order to do this we need to >>>>>>>>>>> record >>>>>>>>>>> what pool a link belonged to, so I think we need to make pool >>>>>>>>>>> part >>>>>>>>>>> of >>>>>>>>>>> the key of the UrlStore object and then populate this field when >>>>>>>>>>> a >>>>>>>>>>> new >>>>>>>>>>> link is created. >>>>>>>>>>> >>>>>>>>>>> Ethan >>>>>>>>>>> >>>>>>>>>>> On Tue, Aug 31, 2010 at 8:11 AM, Imtiaz Ahmed H E >>>>>>>>>>> <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> In the home when I type in a message sharing it with one pool >>>>>>>>>>>> and >>>>>>>>>>>> click >>>>>>>>>>>> resend it does not show up in Popular Messages. But if the >>>>>>>>>>>> message >>>>>>>>>>>> is >>>>>>>>>>>> public >>>>>>>>>>>> it shows up on resend in Popular Pessages. >>>>>>>>>>>> >>>>>>>>>>>> Can you explain. Haven't gotten to Popular Links yet. >>>>>>>>>>>> >>>>>>>>>>>> Imtiaz >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- From: "Ethan Jewett" >>>>>>>>>>>> <[email protected]> >>>>>>>>>>>> To: <[email protected]> >>>>>>>>>>>> Sent: Tuesday, August 31, 2010 11:37 AM >>>>>>>>>>>> Subject: Re: New issues - a couple of blockers for 1.1 release >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> The issue doesn't happen with Popular Messages, only with >>>>>>>>>>>> Popular >>>>>>>>>>>> Links. >>>>>>>>>>>> >>>>>>>>>>>> I need to look into the implementation, but I have a feeling the >>>>>>>>>>>> Popular Links issue is going to be a headache. I believe that >>>>>>>>>>>> for a >>>>>>>>>>>> given link there is no way to tell what message it shows up in, >>>>>>>>>>>> which >>>>>>>>>>>> would make it impossible to tell if it is a link from a pooled >>>>>>>>>>>> message >>>>>>>>>>>> or not. We may have to modify the data model for storing links >>>>>>>>>>>> to >>>>>>>>>>>> flag >>>>>>>>>>>> the ones that started out in a pooled message... >>>>>>>>>>>> >>>>>>>>>>>> Regarding Pubsubhubbub, as Dick said, there's no hurry. I don't >>>>>>>>>>>> think >>>>>>>>>>>> I'll be working on it over the next couple of weeks. >>>>>>>>>>>> >>>>>>>>>>>> Thanks for all your efforts! >>>>>>>>>>>> >>>>>>>>>>>> Ethan >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Aug 31, 2010 at 4:20 AM, Imtiaz Ahmed H E >>>>>>>>>>>> <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Re https://issues.apache.org/jira/browse/ESME-267 >>>>>>>>>>>>> >>>>>>>>>>>>> I haven't tried this but plan to fix it right away. >>>>>>>>>>>>> >>>>>>>>>>>>> Tell me, is it only the links showing up in 'Popular Links' or >>>>>>>>>>>>> is >>>>>>>>>>>>> that >>>>>>>>>>>>> a >>>>>>>>>>>>> problem with the message itself also showing up in >>>>>>>>>>>>> 'PopularMessages' >>>>>>>>>>>>> >>>>>>>>>>>>> Looks like I'll never get going with pubsubhubub ! First there >>>>>>>>>>>>> was >>>>>>>>>>>>> Dick's >>>>>>>>>>>>> Release Planning mail with the pending 1.1 issues and now here >>>>>>>>>>>>> are >>>>>>>>>>>>> some >>>>>>>>>>>>> more. Plan to get going after all 1.1 ending issues are >>>>>>>>>>>>> resolved. >>>>>>>>>>>>> >>>>>>>>>>>>> However, Ethan it was your issue originally and if you feel you >>>>>>>>>>>>> want >>>>>>>>>>>>> to >>>>>>>>>>>>> take >>>>>>>>>>>>> it back again to push it to closure faster or something please >>>>>>>>>>>>> do, >>>>>>>>>>>>> otherwise >>>>>>>>>>>>> I'll re-start on it once 1.1 is done... >>>>>>>>>>>>> >>>>>>>>>>>>> Imtiaz >>>>>>>>>>>>> >>>>>>>>>>>>> ----- Original Message ----- From: "Richard Hirsch" >>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>> To: < >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > >
