Pulp

Return-Path: <rbarlow@redhat.com>

Received: from mi015.mc1.hosteurope.de ([80.237.138.240]) by wp245.webpack.hosteurope.de running ExIM with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1YZ0fG-0001y2-6Z; Fri, 20 Mar 2015 18:24:54 +0100

Received: from mx1.redhat.com ([209.132.183.28]) by mx0.webpack.hosteurope.de (mi015.mc1.hosteurope.de) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) id 1YZ0fF-000143-1N for dropbox+pulp+c71e@plan.io; Fri, 20 Mar 2015 18:24:53 +0100

Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 35413B5994 for <dropbox+pulp+c71e@plan.io>; Fri, 20 Mar 2015 17:24:48 +0000

Received: from where.usersys.redhat.com (ovpn-113-24.phx2.redhat.com [10.3.113.24]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2KHOlKU016620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <dropbox+pulp+c71e@plan.io>; Fri, 20 Mar 2015 13:24:48 -0400

Date: Fri, 20 Mar 2015 13:24:47 -0400

From: Randy Barlow <rbarlow@redhat.com>

To: Pulp <dropbox+pulp+c71e@plan.io>

Message-ID: <550C57DF.7090009@redhat.com>

In-Reply-To: <redmine.journal-2423.20150320155759.38a2892915b5e504@plan.io>

References: <redmine.issue-763.20150316155054@plan.io>

<redmine.journal-2423.20150320155759.38a2892915b5e504@plan.io>

Subject: Re: [Pulp - Story #763] As a user, I can search for Pulp things

without using the word /search/ in the URL

Mime-Version: 1.0

Content-Type: text/plain;

charset=utf-8

Content-Transfer-Encoding: quoted-printable

Delivery-date: Fri, 20 Mar 2015 18:24:54 +0100

Organization: Red Hat, Inc.

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101

Thunderbird/31.5.0

X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26

X-HE-Spam-Level: ----------

X-HE-Spam-Score: -10.0

X-HE-Spam-Report: Content analysis details: (-10.0 points) pts rule name

description ---- ----------------------

-------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL:

Sender listed at http://www.dnswl.org/, high trust [209.132.183.28 listed in

list.dnswl.org] -5.0 PGP_MESSAGE RAW: Contains a PGP signed or encrypted

message

X-HE-SPF: PASSED

Envelope-to: dropbox+pulp+c71e@plan.io

On 03/20/2015 11:58 AM, Pulp wrote:

> Having a /search/ controller sounds fine, but maybe we could consolidat=

e

> them? Currently we have 10, but even with so many, we don't provide

> search capability on many things. With our current design, if you want

> to make a part of Pulp searchable you have to add a new URL even though=

> they all use the "SearchAPI". What if SearchAPI was adjusted slightly t=

o

> allow you to search for all things in Pulp in one place. I think adding=

> an identifier so we know what collection to search in would be the

> adjustment needed. This would make provide one place where users can

> search for anything, and reduce the effort to make new things searchabl=

e

> over time.

> =

> This won't be an amazing improvement, but I do think it is worth the

> effort to do.

> =

> What are thoughts on this type of change?

I agree about not violating the RFCs. I almost wrote a reply to Mike

saying "well alright smyers, quoting the RFCs at us again=E2=80=BD" Hahah=

a.

I like the above suggestion. I think it's pretty much the same as we

have now, but it doesn't collide with the IDs of the objects in the APIs.=

Another possibility would be to move the IDs down a level, maybe

something like this:

/users/search/

/users/id/<user_id>/

That way "search" can't be confused with the user_id.

I think your suggestion is every bit as logical as above, and it also

let's the /users/<user_id>/ remain as it was before, which I think is

also a little cleaner. Because of that, I think I like your suggestion a

little more. I just wanted to mention another option I had considered.

-- =

Randy Barlow