You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Ethan Jewett <es...@gmail.com> on 2010/08/31 08:44:22 UTC
ESME-267 - Pooled links in popular links list
[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 <in...@gmail.com> 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" <es...@gmail.com>
> To: <es...@incubator.apache.org>
> 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 <in...@gmail.com>
> 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"
>> <hi...@gmail.com>
>> To: <es...@incubator.apache.org>
>> Sent: Monday, August 30, 2010 12:00 AM
>> Subject: Re: New issues - a couple of blockers for 1.1 release
>>
>>
>>> On Sun, Aug 29, 2010 at 7:59 PM, Ethan Jewett <es...@gmail.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I've created a few new issues in the Jira based on my testing of the
>>>> latest Stax deployment as well as some local testing. I see a couple
>>>> of them as blockers of the 1.1 release (ESME-266 is definitely
>>>> debatable, but I'm pretty adamant about ESME-267 as it's a real
>>>> security issue):
>>>>
>>>> ESME-266 - https://issues.apache.org/jira/browse/ESME-266 - Some
>>>> RSS/Atom feeds don't work properly. Normally I would have pushed this
>>>> to the backlog, but it makes it so that we can't import Twitter feeds,
>>>> which I think is pretty important.
>>>
>>> +1
>>>
>>>>
>>>> ESME-267 - https://issues.apache.org/jira/browse/ESME-267 - "Links
>>>> from messages in pools show up in "Popular links" for users that are
>>>> not in the pool" - I put an example into the ticket of why this is a
>>>> big problem
>>>
>>> +1 - have you tried to see if resending messages in pools has the same
>>> problem?
>>>
>>>>
>>>> ESME-268 - https://issues.apache.org/jira/browse/ESME-268 - User
>>>> should not be offered the option to "resend" his/her own messages.
>>>> This is assigned to release 1.2 as I don't believe it is a major
>>>> issue. If it is fixed before Dick tags release 1.1, then I'm in favor
>>>> of including it.
>>>
>>> I agree as well
>>>
>>>
>>> Thanks for checking for bugs. I'm sure after we create a RC and people
>>> start testing we will probably find more bugs.
>>>>
>>>> Ethan
>>>>
>>
>>
>
>
Re: ESME-267 - Pooled links in popular links list
Posted by Imtiaz Ahmed H E <in...@gmail.com>.
If 'Popular Messages' come only from the 'public' pool then 'Popular Links'
should also come from links found only in messages from the 'public' pool.
It shouldn't be a big deal to determine whether a message comes from the
'public' pool when a link within it is clicked.
Or am I being too simple for Esme here...
Let me know.
Imtiaz
----- Original Message -----
From: "Vassil Dichev" <vd...@apache.org>
To: <es...@incubator.apache.org>
Sent: Tuesday, August 31, 2010 12:41 PM
Subject: Re: ESME-267 - Pooled links in popular links list
> 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 <es...@gmail.com> 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 <in...@gmail.com>
>> 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" <es...@gmail.com>
>>> To: <es...@incubator.apache.org>
>>> 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 <in...@gmail.com>
>>> 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"
>>>> <hi...@gmail.com>
>>>> To: <es...@incubator.apache.org>
>>>> Sent: Monday, August 30, 2010 12:00 AM
>>>> Subject: Re: New issues - a couple of blockers for 1.1 release
>>>>
>>>>
>>>>> On Sun, Aug 29, 2010 at 7:59 PM, Ethan Jewett <es...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I've created a few new issues in the Jira based on my testing of the
>>>>>> latest Stax deployment as well as some local testing. I see a couple
>>>>>> of them as blockers of the 1.1 release (ESME-266 is definitely
>>>>>> debatable, but I'm pretty adamant about ESME-267 as it's a real
>>>>>> security issue):
>>>>>>
>>>>>> ESME-266 - https://issues.apache.org/jira/browse/ESME-266 - Some
>>>>>> RSS/Atom feeds don't work properly. Normally I would have pushed this
>>>>>> to the backlog, but it makes it so that we can't import Twitter
>>>>>> feeds,
>>>>>> which I think is pretty important.
>>>>>
>>>>> +1
>>>>>
>>>>>>
>>>>>> ESME-267 - https://issues.apache.org/jira/browse/ESME-267 - "Links
>>>>>> from messages in pools show up in "Popular links" for users that are
>>>>>> not in the pool" - I put an example into the ticket of why this is a
>>>>>> big problem
>>>>>
>>>>> +1 - have you tried to see if resending messages in pools has the same
>>>>> problem?
>>>>>
>>>>>>
>>>>>> ESME-268 - https://issues.apache.org/jira/browse/ESME-268 - User
>>>>>> should not be offered the option to "resend" his/her own messages.
>>>>>> This is assigned to release 1.2 as I don't believe it is a major
>>>>>> issue. If it is fixed before Dick tags release 1.1, then I'm in favor
>>>>>> of including it.
>>>>>
>>>>> I agree as well
>>>>>
>>>>>
>>>>> Thanks for checking for bugs. I'm sure after we create a RC and people
>>>>> start testing we will probably find more bugs.
>>>>>>
>>>>>> Ethan
>>>>>>
>>>>
>>>>
>>>
>>>
>>
Re: Fw: ESME - 266 - my fix in progress, hopefully...
Posted by Imtiaz Ahmed H E <in...@gmail.com>.
Sorry, I posted the mail in the wrong thread. I have now changed the subject
line.
My concern is, "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
say, FeedReader (perhaps any other feed reader app too) sets up the feed
correctly.
So, should we handle this in Esme too... CAN WE ? Should I?
By the way what about the Twitter problem in the mail I sent along with the
nytimes proble (see below).
Imtiaz
----- Original Message -----
From: "Vassil Dichev" <vd...@apache.org>
To: <es...@incubator.apache.org>
Sent: Friday, September 03, 2010 10:41 AM
Subject: Re: ESME-267 - Pooled links in popular links list
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 <in...@gmail.com>
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" <vd...@apache.org>
> To: <es...@incubator.apache.org>
> 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 <hi...@gmail.com>
>> wrote:
>>>
>>> Sounds like a god idea.
>>>
>>> D.
>>>
>>> On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <hi...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Leave original link but just don't add it to PopularLinks.
>>>>>
>>>>> On 8/31/10, Ethan Jewett <es...@gmail.com> 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
>>>>>> <hi...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> I agree with the solution of just removing those links that
>>>>>>> originate
>>>>>>> in
>>>>>>> pools.
>>>>>>>
>>>>>>> D.
>>>>>>>
>>>>>>> On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <es...@gmail.com>
>>>>>>>> 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 <vd...@apache.org>
>>>>>>>>> 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
>>>>>>>>>> <es...@gmail.com>
>>>>>>>>>> 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
>>>>>>>>>>> <in...@gmail.com>
>>>>>>>>>>> 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"
>>>>>>>>>>>> <es...@gmail.com>
>>>>>>>>>>>> To: <es...@incubator.apache.org>
>>>>>>>>>>>> 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
>>>>>>>>>>>> <in...@gmail.com>
>>>>>>>>>>>> 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"
>>>>>>>>>>>>> <hi...@gmail.com>
>>>>>>>>>>>>> To: <
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
>
Re: ESME-267 - Pooled links in popular links list
Posted by Vassil Dichev <vd...@apache.org>.
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 <in...@gmail.com> 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" <vd...@apache.org>
> To: <es...@incubator.apache.org>
> 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 <hi...@gmail.com>
>> wrote:
>>>
>>> Sounds like a god idea.
>>>
>>> D.
>>>
>>> On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <hi...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Leave original link but just don't add it to PopularLinks.
>>>>>
>>>>> On 8/31/10, Ethan Jewett <es...@gmail.com> 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
>>>>>> <hi...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> I agree with the solution of just removing those links that originate
>>>>>>> in
>>>>>>> pools.
>>>>>>>
>>>>>>> D.
>>>>>>>
>>>>>>> On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <es...@gmail.com>
>>>>>>>> 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 <vd...@apache.org>
>>>>>>>>> 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 <es...@gmail.com>
>>>>>>>>>> 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
>>>>>>>>>>> <in...@gmail.com>
>>>>>>>>>>> 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"
>>>>>>>>>>>> <es...@gmail.com>
>>>>>>>>>>>> To: <es...@incubator.apache.org>
>>>>>>>>>>>> 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
>>>>>>>>>>>> <in...@gmail.com>
>>>>>>>>>>>> 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"
>>>>>>>>>>>>> <hi...@gmail.com>
>>>>>>>>>>>>> To: <
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
>
Re: ESME-267 - Pooled links in popular links list
Posted by Imtiaz Ahmed H E <in...@gmail.com>.
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" <vd...@apache.org>
To: <es...@incubator.apache.org>
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 <hi...@gmail.com>
> wrote:
>> Sounds like a god idea.
>>
>> D.
>>
>> On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <hi...@gmail.com>
>>> wrote:
>>>> Leave original link but just don't add it to PopularLinks.
>>>>
>>>> On 8/31/10, Ethan Jewett <es...@gmail.com> 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
>>>>> <hi...@gmail.com>
>>>>> wrote:
>>>>>> I agree with the solution of just removing those links that originate
>>>>>> in
>>>>>> pools.
>>>>>>
>>>>>> D.
>>>>>>
>>>>>> On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <es...@gmail.com>
>>>>>>> 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 <vd...@apache.org>
>>>>>>>> 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 <es...@gmail.com>
>>>>>>>>> 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
>>>>>>>>>> <in...@gmail.com>
>>>>>>>>>> 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"
>>>>>>>>>>> <es...@gmail.com>
>>>>>>>>>>> To: <es...@incubator.apache.org>
>>>>>>>>>>> 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
>>>>>>>>>>> <in...@gmail.com>
>>>>>>>>>>> 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"
>>>>>>>>>>>> <hi...@gmail.com>
>>>>>>>>>>>> To: <
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Re: ESME-267 - Pooled links in popular links list
Posted by Vassil Dichev <vd...@apache.org>.
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 <hi...@gmail.com> wrote:
> Sounds like a god idea.
>
> D.
>
> On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <hi...@gmail.com>
>> wrote:
>>> Leave original link but just don't add it to PopularLinks.
>>>
>>> On 8/31/10, Ethan Jewett <es...@gmail.com> 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 <hi...@gmail.com>
>>>> wrote:
>>>>> I agree with the solution of just removing those links that originate in
>>>>> pools.
>>>>>
>>>>> D.
>>>>>
>>>>> On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <es...@gmail.com>
>>>>>> 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 <vd...@apache.org> 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 <es...@gmail.com>
>>>>>>>> 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
>>>>>>>>> <in...@gmail.com>
>>>>>>>>> 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"
>>>>>>>>>> <es...@gmail.com>
>>>>>>>>>> To: <es...@incubator.apache.org>
>>>>>>>>>> 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
>>>>>>>>>> <in...@gmail.com>
>>>>>>>>>> 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"
>>>>>>>>>>> <hi...@gmail.com>
>>>>>>>>>>> To: <
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: ESME-267 - Pooled links in popular links list
Posted by Richard Hirsch <hi...@gmail.com>.
Sounds like a god idea.
D.
On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <hi...@gmail.com>
> wrote:
>> Leave original link but just don't add it to PopularLinks.
>>
>> On 8/31/10, Ethan Jewett <es...@gmail.com> 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 <hi...@gmail.com>
>>> wrote:
>>>> I agree with the solution of just removing those links that originate in
>>>> pools.
>>>>
>>>> D.
>>>>
>>>> On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <es...@gmail.com>
>>>>> 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 <vd...@apache.org> 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 <es...@gmail.com>
>>>>>>> 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
>>>>>>>> <in...@gmail.com>
>>>>>>>> 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"
>>>>>>>>> <es...@gmail.com>
>>>>>>>>> To: <es...@incubator.apache.org>
>>>>>>>>> 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
>>>>>>>>> <in...@gmail.com>
>>>>>>>>> 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"
>>>>>>>>>> <hi...@gmail.com>
>>>>>>>>>> To: <
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: ESME-267 - Pooled links in popular links list
Posted by Vassil Dichev <vd...@apache.org>.
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 <hi...@gmail.com> wrote:
> Leave original link but just don't add it to PopularLinks.
>
> On 8/31/10, Ethan Jewett <es...@gmail.com> 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 <hi...@gmail.com>
>> wrote:
>>> I agree with the solution of just removing those links that originate in
>>> pools.
>>>
>>> D.
>>>
>>> On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <es...@gmail.com>
>>>> 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 <vd...@apache.org> 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 <es...@gmail.com>
>>>>>> 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
>>>>>>> <in...@gmail.com>
>>>>>>> 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"
>>>>>>>> <es...@gmail.com>
>>>>>>>> To: <es...@incubator.apache.org>
>>>>>>>> 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
>>>>>>>> <in...@gmail.com>
>>>>>>>> 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"
>>>>>>>>> <hi...@gmail.com>
>>>>>>>>> To: <
>>>>>
>>>>
>>>
>>
>
Re: ESME-267 - Pooled links in popular links list
Posted by Richard Hirsch <hi...@gmail.com>.
Leave original link but just don't add it to PopularLinks.
On 8/31/10, Ethan Jewett <es...@gmail.com> 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 <hi...@gmail.com>
> wrote:
>> I agree with the solution of just removing those links that originate in
>> pools.
>>
>> D.
>>
>> On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <es...@gmail.com>
>>> 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 <vd...@apache.org> 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 <es...@gmail.com>
>>>>> 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
>>>>>> <in...@gmail.com>
>>>>>> 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"
>>>>>>> <es...@gmail.com>
>>>>>>> To: <es...@incubator.apache.org>
>>>>>>> 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
>>>>>>> <in...@gmail.com>
>>>>>>> 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"
>>>>>>>> <hi...@gmail.com>
>>>>>>>> To: <
>>>>
>>>
>>
>
Re: ESME-267 - Pooled links in popular links list
Posted by Ethan Jewett <es...@gmail.com>.
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 <hi...@gmail.com> wrote:
> I agree with the solution of just removing those links that originate in pools.
>
> D.
>
> On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <es...@gmail.com> 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 <vd...@apache.org> 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 <es...@gmail.com> 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 <in...@gmail.com>
>>>>> 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" <es...@gmail.com>
>>>>>> To: <es...@incubator.apache.org>
>>>>>> 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 <in...@gmail.com>
>>>>>> 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"
>>>>>>> <hi...@gmail.com>
>>>>>>> To: <
>>>
>>
>
Re: ESME-267 - Pooled links in popular links list
Posted by Richard Hirsch <hi...@gmail.com>.
I agree with the solution of just removing those links that originate in pools.
D.
On 8/31/10, Vassil Dichev <vd...@apache.org> 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 <es...@gmail.com> 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 <vd...@apache.org> 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 <es...@gmail.com> 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 <in...@gmail.com>
>>>> 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" <es...@gmail.com>
>>>>> To: <es...@incubator.apache.org>
>>>>> 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 <in...@gmail.com>
>>>>> 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"
>>>>>> <hi...@gmail.com>
>>>>>> To: <
>>
>
Re: ESME-267 - Pooled links in popular links list
Posted by Ethan Jewett <es...@gmail.com>.
Hi Vassil,
Assuming we have a problem (it sounds to me like this is up for
debate), I think a reasonable solution that doesn't reduce
functionality or defeat the purpose of short-links is to modify the
URL store to keep short-links found in public messages separate from
short-links found in pools. We could do this be adding a mapped
boolean flag attribute to the UrlStore class. We could also separate
short-links by pool, as you suggest, by storing the pool as an
attribute of the UrlStore class.
Either way we could make it so that clicks on links from pools don't
increment the counter, so links found only in pools will never appear
in the "Popular links" list.
What do you think? Are we going to run into problems with that? Will
this break any other functionality?
Ethan
On Tue, Aug 31, 2010 at 11:52 AM, Vassil Dichev <vd...@apache.org> 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 <es...@gmail.com> 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 <vd...@apache.org> 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 <es...@gmail.com> 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 <in...@gmail.com> 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" <es...@gmail.com>
>>>>> To: <es...@incubator.apache.org>
>>>>> 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 <in...@gmail.com>
>>>>> 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"
>>>>>> <hi...@gmail.com>
>>>>>> To: <
>>
>
Re: ESME-267 - Pooled links in popular links list
Posted by Vassil Dichev <vd...@apache.org>.
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 <es...@gmail.com> 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 <vd...@apache.org> 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 <es...@gmail.com> 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 <in...@gmail.com> 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" <es...@gmail.com>
>>>> To: <es...@incubator.apache.org>
>>>> 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 <in...@gmail.com>
>>>> 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"
>>>>> <hi...@gmail.com>
>>>>> To: <
>
Re: ESME-267 - Pooled links in popular links list
Posted by Ethan Jewett <es...@gmail.com>.
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 <vd...@apache.org> 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 <es...@gmail.com> 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 <in...@gmail.com> 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" <es...@gmail.com>
>>> To: <es...@incubator.apache.org>
>>> 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 <in...@gmail.com>
>>> 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"
>>>> <hi...@gmail.com>
>>>> To: <
Re: ESME-267 - Pooled links in popular links list
Posted by Vassil Dichev <vd...@apache.org>.
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 <es...@gmail.com> 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 <in...@gmail.com> 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" <es...@gmail.com>
>> To: <es...@incubator.apache.org>
>> 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 <in...@gmail.com>
>> 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"
>>> <hi...@gmail.com>
>>> To: <es...@incubator.apache.org>
>>> Sent: Monday, August 30, 2010 12:00 AM
>>> Subject: Re: New issues - a couple of blockers for 1.1 release
>>>
>>>
>>>> On Sun, Aug 29, 2010 at 7:59 PM, Ethan Jewett <es...@gmail.com> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I've created a few new issues in the Jira based on my testing of the
>>>>> latest Stax deployment as well as some local testing. I see a couple
>>>>> of them as blockers of the 1.1 release (ESME-266 is definitely
>>>>> debatable, but I'm pretty adamant about ESME-267 as it's a real
>>>>> security issue):
>>>>>
>>>>> ESME-266 - https://issues.apache.org/jira/browse/ESME-266 - Some
>>>>> RSS/Atom feeds don't work properly. Normally I would have pushed this
>>>>> to the backlog, but it makes it so that we can't import Twitter feeds,
>>>>> which I think is pretty important.
>>>>
>>>> +1
>>>>
>>>>>
>>>>> ESME-267 - https://issues.apache.org/jira/browse/ESME-267 - "Links
>>>>> from messages in pools show up in "Popular links" for users that are
>>>>> not in the pool" - I put an example into the ticket of why this is a
>>>>> big problem
>>>>
>>>> +1 - have you tried to see if resending messages in pools has the same
>>>> problem?
>>>>
>>>>>
>>>>> ESME-268 - https://issues.apache.org/jira/browse/ESME-268 - User
>>>>> should not be offered the option to "resend" his/her own messages.
>>>>> This is assigned to release 1.2 as I don't believe it is a major
>>>>> issue. If it is fixed before Dick tags release 1.1, then I'm in favor
>>>>> of including it.
>>>>
>>>> I agree as well
>>>>
>>>>
>>>> Thanks for checking for bugs. I'm sure after we create a RC and people
>>>> start testing we will probably find more bugs.
>>>>>
>>>>> Ethan
>>>>>
>>>
>>>
>>
>>
>