[Pulp-list] Client Refactoring

[James Slagle]

On Wed, Jul 20, 2011 at 02:01:16PM -0600, Jason L Connor wrote:
> I take the "4 main goals" are the projected finished product of this
> effort. I noticed the server proxy isn't mentioned as a separate
> component. Do you see this as part of the API Library?

By server proxy do you mean what's in pulp.client.server?  If so, then yes, I
had envinsioned that as part of the API library.

> 
> Under the API Library, what do you mean by "interactive mode" and what
> will it buy us over using the python interpreter directly to explore the
> API?

That's basically what I meant; I'll make that clearer on the wiki page.
Basically, make what happens in pulp.client.cli.admin|consumer, happen as part
of a __main__, so that it's easier to get setup interactively.  That way, you
wouldn't have to write a small script to set things like the config and server
up for you in order to explore the API.

> I really like the model classes. They make a lot more sense that the
> argument heavy api we have today. However, how do you plan to map the
> model classes to the appropriate rest call? Will the models themselves
> know about the url paths?

There's 2 ways how I see it could go.

First, you instantiate the model class, such as Consumer() and set the
appropriate fields.  We could then call a create method on that instance, such
as consumer.create().  That method would have to make use of the API, know
which url to use, use the active server, etc.  

Secondly, the instantiated model could be passed to the create method of an
instance of the ConsumerAPI().  This is similar to what happens today,
although instead of passing in a larger number of arguments, you pass in a
model class.

Actually, a third way would be a combination of the 2.  The consumer
instance's create method acts more like a convenience method and uses the
ConsumerAPI().create, passing in itself as the model to create.

I think I would prefer the first way.  It would behave a lot like many ORM's
do.  The model would have to know it's url, but there could be a lot of code
reuse from a base class, such as the create() method, which would be basically
the same for almost every model (you just hit a different url).

> Under the admin client, what is the difference between a plugin
> architecture and what we have today with the command and action classes?
> Question also applies to the consumer framework.

Practically nothing.  Moving to plugins would allow for custom commands to
support different types of content without having to update the admin/client
code itself.  As part of plugin discovery/registration the commands and
actions would be added similarly to how they are each listed individually now
in the setup methods.  One beneift would be if the community wanted to develop
a plugin to support a particular type of content that we didn't want to merge
into pulp master, for whatever reason.

One difference would be that as plugins, they may expose additional config
that would need to be read and merged into the main config.

> Under the consumer framework, do you envision the same plugins to be
> used by both the command line tools and by the gofer daemon?

I'm not 100% on this yet, but it could be that there is one gofer plugin that
acts as some glue code to map gofer messages to the discovered plugins that
have registered themselves in some way as to handle certain message types.  

Using the same plugins in both gofer and the cli is a possibility, although
I'm not all sure what that would entail.

--
-- James Slagle
--