Launchpad itself

Bug #325982
Comment #3

Comment 3 for bug 325982

Revision history for this message

Karl Fogel (kfogel) wrote on 2009-09-09:

micahg and I had a long conversation about this in IRC.

Summary is: even though most of the fields in that URL just represent defaults, they still hold information. If Launchpad's defaults were to change, the meaning of the URL wouldn't change -- unless we shortened the URL, thus depending on Launchpad to know what the defaults should be: then if Launchpad's defaults changed, the meaning of the query would change too.

I'm not sure whether that means the proposed fix is a good or bad idea. However, it does mean that this bug might be alleviated by a fix to bug #317136 ("Launchpad should offer a 'Get tinyURL link' option for each page"), which has its own rather intricate discussion.

Here's the conversation between micahg and me today:

-----------------------------------------------

<micahg> kfogel: what do you think of that idea of bookmarked
queries?

<micahg> then you can use post for everything

<micahg> in the app at least

<micahg> and leave $_GET for the people who want to pull data

<kfogel> micahg: can you explain in more detail? I'm not sure I
understand.

  <kfogel> micahg: I mean, this is more about the URLs themselves --
             making them more palatable when pasted into emails or other
             forums.

<micahg> kfogel: that would make the url smaller
https://bugs.launchpad.net/?bookmarkq=1589654

<kfogel> micahg: AH, I see what you mean.

  <kfogel> micahg: I think implementation-wise that would have a
             greater impact on the rest of Launchpad (because now we
             have to have the DB remember all those bookmarks), and it
             would make the meaning of the URL more obscure (== less
             hackable).

  <kfogel> micahg: IOW, I think jml's suggestion in
             https://bugs.edge.launchpad.net/malone/+bug/325982/comments/2
             is a cleaner fix.

<micahg> kfogel: but it wouldn't shorten it much

<kfogel> micahg: well, the length would now be proportional to the
complexity of the query, sure.

<kfogel> micahg: all the unspecified fields would be left off.

<micahg> yes, but most queries do have a lot ofs option

  <kfogel> micahg: I think the idea behind the bug is that when the
             specified value is the same as the default, you can leave
             it off the URL.

<kfogel> micahg: but you do have a point -- what if the defaults
change? Should the meaning of the query then change?

<micahg> because the url has the defaults right now

  <kfogel> micahg: yeah, the state is carried in the URL, not in
             Launchpad -- even if Launchpad's search query defaults
             change, the URL will still mean the same thing.

<micahg> right, that's what I meant by not shortening it too much

  <kfogel> micahg: this ties into another bug we had about making a
             dedicated tinyurl service, which got swamped by discussion
             of why it's a bad idea IIRC. Let me see if I can dig it
             up.

<micahg> kfogel: it seems like if people could "send" queries to
other users, that would help also

<micahg> then the user can see a list of their queries and what they
are

<kfogel> micahg: https://dev.launchpad.net/Wishes/PersonalDashboard
:-)

<micahg> kfogel: it would tie in great there :)

<kfogel> micahg:
https://bugs.edge.launchpad.net/launchpad-foundations/+bug/317136

  <kfogel> micahg: I'm going to add a comment there, with our
             discussion (paraphrased), and make sure the two bugs know
             about each other.

<micahg> sounds good

<micahg> I would suggest sticking with numeric urls though to speed
up the query from the db

<kfogel> micahg: maybe; might be overoptimization, I don't know
enough about the DB to say for sure.

<micahg> kfogel: numeric column ids are normally the fastest in most
engines AFAIK

  <kfogel> micahg: oh, I agree they're faster, the question is whether
             the cost matters -- i.e., if that's just not a bottleneck,
             then speeding it up doesn't gain us much.

  <micahg> kfogel: well, think about how many users will want short
             urls and the use of LP, isn't the DB already a bottleneck
             for LP?

  <micahg> especially if you have to store 41 trillion like you
             posted, wouldn't you want any speed increase possible at
             that point?

  <kfogel> micahg: not necessarily; it all has to do with usage
             patterns. note, for example, that TinyURL.com doesn't use
             numerics, although they could. Possibly they're
             translating alphanumerics to a number and then using that,
             who knows. Lots of strategies available. I think the way
             to do it is to determine what we want users to see, first,
             and then work backwards from there.

<micahg> ok

<kfogel> micahg: (i.e., "digits" != "number")

<kfogel> and "alphanumeric" != "!number" :-)

<micahg> I guess I think more in the implementation than
presentation :)

<kfogel> micahg: my feeling is, the user is only going to see the
presentation, so... :-)

<micahg> right

micahg and I had a long conversation about this in IRC.

Summary is: even though most of the fields in that URL just represent defaults, they still hold information.  If Launchpad's defaults were to change, the meaning of the URL wouldn't change -- unless we shortened the URL, thus depending on Launchpad to know what the defaults should be: then if Launchpad's defaults changed, the meaning of the query would change too.

I'm not sure whether that means the proposed fix is a good or bad idea.  However, it does mean that this bug might be alleviated by a fix to bug #317136 ("Launchpad should offer a 'Get tinyURL link' option for each page"), which has its own rather intricate discussion.

Here's the conversation between micahg and me today:

-----------------------------------------------

<micahg>   kfogel: what do you think of that idea of bookmarked
             queries?
  
  <micahg>   then you can use post for everything
  
  <micahg>   in the app at least
  
  <micahg>   and leave $_GET for the people who want to pull data
  
  <kfogel>   micahg: can you explain in more detail?  I'm not sure I
             understand.
  
  <kfogel>   micahg: I mean, this is more about the URLs themselves --
             making them more palatable when pasted into emails or other
             forums.
  
  <micahg>   kfogel: that would make the url smaller
             https://bugs.launchpad.net/?bookmarkq=1589654
  
  <kfogel>   micahg: AH, I see what you mean.
  
  <kfogel>   micahg: I think implementation-wise that would have a
             greater impact on the rest of Launchpad (because now we
             have to have the DB remember all those bookmarks), and it
             would make the meaning of the URL more obscure (== less
             hackable).
  
  <kfogel>   micahg: IOW, I think jml's suggestion in
             https://bugs.edge.launchpad.net/malone/+bug/325982/comments/2
             is a cleaner fix.
  
  <micahg>   kfogel: but it wouldn't shorten it much
  
  <kfogel>   micahg: well, the length would now be proportional to the
             complexity of the query, sure.
  
  <kfogel>   micahg: all the unspecified fields  would be left off.
  
  <micahg>   yes, but most queries do have a lot ofs option
  
  <kfogel>   micahg: I think the idea behind the bug is that when the
             specified value is the same as the default, you can leave
             it off the URL.
  
  <kfogel>   micahg: but you do have a point -- what if the defaults
             change?  Should the meaning of the query then change?
  
  <micahg>   because the url has the defaults right now
  
  <kfogel>   micahg: yeah, the state is carried in the URL, not in
             Launchpad -- even if Launchpad's search query defaults
             change, the URL will still mean the same thing.
  
  <micahg>   right, that's what I meant by not shortening it too much
  
  <kfogel>   micahg: this ties into another bug we had about making a
             dedicated tinyurl service, which got swamped by discussion
             of why it's a bad idea IIRC.  Let me see if I can dig it
             up.
  
  <micahg>   kfogel: it seems like if people could "send" queries to
             other users, that would help also
  
  <micahg>   then the user can see a list of their queries and what they
             are
  
  <kfogel>   micahg: https://dev.launchpad.net/Wishes/PersonalDashboard
             :-)
  
  <micahg>   kfogel: it would tie in great there :)
  
  <kfogel>   micahg:
             https://bugs.edge.launchpad.net/launchpad-foundations/+bug/317136
  
  <kfogel>   micahg: I'm going to add a comment there, with our
             discussion (paraphrased), and make sure the two bugs know
             about each other.
  
  <micahg>   sounds good
  
  <micahg>   I would suggest sticking with numeric urls though to speed
             up the query from the db
  
  <kfogel>   micahg: maybe; might be overoptimization, I don't know
             enough about the DB to say for sure.
  
  <micahg>   kfogel: numeric column ids are normally the fastest in most
             engines AFAIK
  
  <kfogel>   micahg: oh, I agree they're faster, the question is whether
             the cost matters -- i.e., if that's just not a bottleneck,
             then speeding it up doesn't gain us much.
  
  <micahg>   kfogel: well, think about how many users will want short
             urls and the use of LP, isn't the DB already a bottleneck
             for LP?
  
  <micahg>   especially if you have to store 41 trillion like you
             posted, wouldn't you want any speed increase possible at
             that point?
  
  <kfogel>   micahg: not necessarily; it all has to do with usage
             patterns.  note, for example, that TinyURL.com doesn't use
             numerics, although they could.  Possibly they're
             translating alphanumerics to a number and then using that,
             who knows.  Lots of strategies available.  I think the way
             to do it is to determine what we want users to see, first,
             and then work backwards from there.
  
  <micahg>   ok
  
  <kfogel>   micahg: (i.e., "digits" != "number")
  
  <kfogel>   and "alphanumeric" != "!number" :-)
  
  <micahg>   I guess I think more in the implementation than
             presentation :)
  
  <kfogel>   micahg: my feeling is, the user is only going to see the
             presentation, so... :-)
  
  <micahg>   right