Here is a patch with my last updates: https://issues.apache.org/jira/browse/TUSCANY-2435
The main changes are: - Added support for query operations; - GDataBindingInvoker extends DataExchangeSemantics, avoiding the problem with marshal/unmarshal com.google.gdata.data.Feed objects; I have had some issues when creating the patch, so if you have any problem when applying the it please tell me. Thanks Luciano for the comments above and the changes done. Other comments inline On Tue, Jun 24, 2008 at 6:10 AM, Luciano Resende <[EMAIL PROTECTED]> wrote: > I have committed the proposed changes under svn revision #671075 > Please let me know if you find any issues. > > On Mon, Jun 23, 2008 at 6:02 PM, Luciano Resende <[EMAIL PROTECTED]> > wrote: > > Re-sending as this might not have reached the mailing list. > > > > On Mon, Jun 23, 2008 at 11:33 AM, Luciano Resende <[EMAIL PROTECTED]> > wrote: > >> After reviewing this again over the weekend, I have couple suggestions : > >> > >> 1.Looks like we are creating a new binding-gdata here, but still > >> relying on the binding-atom model objects. I'd recommend creating the > >> model objects particular to binding-gdata (even if it's same for now) > >> in a binding-gdata module, and rename the current binding-gdata to > >> binding-gdata-runtime to follow the naming standar used in other > >> modules. This should also cause some name changes in packages and > >> implementation objects. > >> > >> 2.Looks like we are defining a new collection interface in > >> binding-gdata, I'd like to understand better if there are any issues > >> on using the one defined in data-api before creating a new collection > >> interface > I am not sure, but if I understood right, you suggest to create something like GDataCollection extends Collection<String, com.google.gdata.data.BaseEntry>(1) instead of define a new collection(2). In this way, most of the methods would be very similiar (post, get, put, delete). But, and how about the getAll() and query() methods? The current implemention define that methods like this: *com.google.gdata.data.Feed getFeed(); com.google.gdata.data.Feed query(String queryString);* Using 1 we would have something like this: *Entry<String, BaseEntry>[] getAll(); Entry<String, BaseEntry>[] query(String queryString);* The main disadvantage that I can notice in approach 1 is the lost of information about the feed. Informations like authors, categories, last updates, links, and other related to the feed would not be retrieved since we have just an array. > > >> > >> 3.We should work together to find a solution to have the gdata > >> dependencies available trough maven. If there isn't one available > >> already, we could publish it to a internal repo in my apache account > >> (I have looked in how to do this over the weekend already). This would > >> be a requirement for this project, but for Haibo Zao project as well, > >> so we should collaborate in finding a solution. > >> > >> If you are ok, and don't have much changes locally, I could handle 1 > >> and 2 later today or tomorrow. > >> > >> Thanks > >> > >> On Sun, Jun 8, 2008 at 7:59 AM, Douglas Leite <[EMAIL PROTECTED]> > wrote: > >>> The link to the patch: > https://issues.apache.org/jira/browse/TUSCANY-2376 > >>> > >>> On Fri, Jun 6, 2008 at 10:51 PM, Douglas Leite <[EMAIL PROTECTED]> > wrote: > >>> > >>>> I have started to define the structure and some classes to allow the > GData > >>>> binding, as discussed above. > >>>> > >>>> This project was created following the binding-atom-abdera project > >>>> structure. So there is some dependencies that need to be revised. > >>>> > >>>> The initial created classes aim to handle with the reference side of a > >>>> component. So, at this moment, an component would invoke only a Google > >>>> service, instead of a service provided by another SCA component. > >>>> > >>>> I have started to implement the invokers, starting with the > GetAllInvoker, > >>>> as simple as possible (just for some tests). I have got an error at > the > >>>> moment to retrieve the feed object (com.google.gdata.data.Feed) from > the > >>>> message object (org.apache.tuscany.sca.invocation.Message). > >>>> > >>>> I am not updated about the discussion evolving the license of the > GData > >>>> Java Client. However, this first implementation is using the GData > Java > >>>> Client. > >>>> > >>>> Douglas > >>>> > >>>> > >>>> On Tue, Jun 3, 2008 at 4:26 AM, Mike Edwards < > >>>> [EMAIL PROTECTED]> wrote: > >>>> > >>>>> Luciano Resende wrote: > >>>>> > >>>>>> Hey Mike > >>>>>> > >>>>>> What are your concerns with regards to license ? Looking at [1], > it > >>>>>> looks like the GData Java Client is Apache License 2. > >>>>>> > >>>>>> [1] http://code.google.com/p/gdata-java-client/ > >>>>>> > >>>>>> On Mon, Jun 2, 2008 at 10:01 PM, Mike Edwards > >>>>>> <[EMAIL PROTECTED]> wrote: > >>>>>> > >>>>>>> Douglas Leite wrote: > >>>>>>> > >>>>>>>> After analyzing the Google Data API and the code of binding-atom, > >>>>>>>> binding-atom-abdera, and binding-feed, I propose an approach to > start > >>>>>>>> the > >>>>>>>> development of the GData biding. > >>>>>>>> > >>>>>>>> I propose creating a new type of binding: biding-gdata. Similarly > as > >>>>>>>> binding-atom-abdera, that extends the binding-atom, this new kind > of > >>>>>>>> binding > >>>>>>>> would extend the binding-atom too. > >>>>>>>> > >>>>>>>> The implementation of the invokers (linke GetInvoker, PostInvoker, > and > >>>>>>>> PutInvoker) would be done using the GData Java Client, that > provides > >>>>>>>> tools > >>>>>>>> and an abstract layer, abstracting the necessity of handling with > HTTP > >>>>>>>> requests/responses and XML's processing. > >>>>>>>> > >>>>>>>> The binding-gdata could extend the binding-rss aiming to allow RSS > >>>>>>>> feeds. > >>>>>>>> > >>>>>>>> This approach looks like the binding-feed, but reusing the > binding-atom > >>>>>>>> and > >>>>>>>> binding-rss, and using the GData Java Client to implement the > invokers. > >>>>>>>> > >>>>>>>> What do you think about? > >>>>>>>> > >>>>>>>> Douglas, > >>>>>>> > >>>>>>> We need to take some care over the idea of using the GData Java > Client - > >>>>>>> we > >>>>>>> need to check out the legal terms that apply to the client code, > since > >>>>>>> it > >>>>>>> does not appear to have a license that is compatible with the > Apache > >>>>>>> open > >>>>>>> source license, as far as I can tell. > >>>>>>> > >>>>>>> I'm not saying that you can't use the Google code, but we do need > to ask > >>>>>>> to > >>>>>>> see what the right way would be to use this code. > >>>>>>> > >>>>>>> > >>>>>>> Yours, Mike. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> Luciano, > >>>>> > >>>>> What about this page, linked off the one above: > >>>>> > >>>>> http://code.google.com/tos.html > >>>>> > >>>>> Yours, Mike. > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Douglas Siqueira Leite > >>>> Computer Science Master's degree student of University of Campinas > >>>> (Unicamp) > >>>> > >>> > >>> > >>> > >>> -- > >>> Douglas Siqueira Leite > >>> Computer Science Master's degree student of University of Campinas > (Unicamp) > >>> > >> > >> > >> > >> -- > >> Luciano Resende > >> Apache Tuscany Committer > >> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende> > >> http://lresende.blogspot.com/ > >> > > > > > > > > -- > > Luciano Resende > > Apache Tuscany Committer > > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende> > > http://lresende.blogspot.com/ > > > > > > -- > Luciano Resende > Apache Tuscany Committer > http://people.apache.org/~lresende <http://people.apache.org/%7Elresende> > http://lresende.blogspot.com/ > -- Douglas Siqueira Leite Computer Science Master's degree student of University of Campinas (Unicamp)
