[Pulp-list] Client Refactoring

[Jason L Connor]

Thanks for replying James. I think I have a better idea of what you guys
have in mind now.

On Wed, 2011-07-20 at 16:59 -0400, James Slagle wrote:
> > 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).

I like the first idea as well. Simply make the model classes themselves
be clients of the api library.


> > 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. 

This is an interesting area. It'd be nice to get some sort of code reuse
for functionality common to both the consumer cli tools and the consumer
gofer daemon. However, if it's too much of a hassle, I think we should
probably punt on it. 

I'm looking forward to the deep dive and how you flush some of these
things out :)

-- 
Jason L Connor
linear on freenode #pulp
http://pulpproject.org/
RHCE: 805010912355231
GPG Fingerprint: 2048R/CC4ED7C1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20110720/d57bae89/attachment.sig>