You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Michelle Zhang <zh...@gmail.com> on 2017/04/01 02:30:42 UTC

Re: GSoC Message Queue proposal


On 2017-03-31 16:01 (-0400), Ignasi Barrera <na...@apache.org> wrote: 
> Hi Michelle,
> 
> The proposal looks great! It is a very good starting point.
> 
> Regarding the mapping between the portable model and the provider one
> (message structure, etc) you'll probably have to define a set of
> transformation functions in each provider. Regarding this, the BlobStore
> abstraction and the Compute one work a bit different: the former just
> provides the interface and lets each implementation transform the data, and
> the latter provides an adapter layer [1], so implementations can be written
> using exclusively the provider model, and the adapter layer will take care
> of calling the transformation functions where needed (they just need to be
> bound to the Guice context).
> 
> This could affect the design of the abstraction and how implementations are
> coded, so you probably want to think about this when working on the
> proposal.
> 
> 
> I.
> 
> [1]
> https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/ComputeServiceAdapter.java
> 
> 
> 
> 
> On Mar 31, 2017 7:37 AM, "Michelle Zhang" <zh...@gmail.com>
> wrote:
> 
> > Hello,
> > I've finished my proposal for GSoC problem "Create Message Queue
> > Abstraction". The problem link: https://issues.apache.org/jira
> > /browse/JCLOUDS-865?jql=labels%20%3D%20gsoc2017%20AND%20proj
> > ect%20%3D%20jclouds
> >
> > I have discussed with mentor Andrew Gaul and we decide to share it here to
> > get more good ideas. Please give me more suggestions! ;-) Thank you so much!
> >
> > proposal link: https://docs.google.com/docume
> > nt/d/1QEy2DsLijWf5g6CmmOegzCEbF_CBE3dM767sJb7AY0Y/edit?usp=sharing
> >
> > Thanks,
> > ~Michelle
> >
> Thanks a lot for the high-quality feedbacks! Originally I thought when the abstraction is completed, we could implement the provider as a subclass of the abstraction. While right now I agree that adapter is better.