You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Douglas Leite <do...@gmail.com> on 2008/07/30 06:43:30 UTC
Re: [GSoC] [DISCUSS] Development of GData biding
During the mid-term evaluation I could realize the main issues related to
the binding-gdata module that I am developing. They were:
1) The current state of binding.gdata only supports operations done with
Google Calendar Service;
2) A component that uses a binding.gdata can only access Google services.
There is still not a way to a component provide a GData service;
3) The authentication is done by passing the username and password
information through the Service Component Definition Language (SCDL) file –
there is still not any data encryption;
4) Operations to work with media types are not available yet.
Because 1 and 2 implies directly on the correct behavior of the binding, I
concentrated my efforts on resolving them.
About 1:
A new attribute was created to be used in SCDL file: *serviceType*. This
attribute is used to specify the kind of service that the binding will
handle with, like "cl" to Calendar, "blogger" to Blogger, or "mail" to
GMail. So, we have something like this:
*<binding.gdata uri="..." username="..." password="..."
serviceType="cl"/> *
About 2:
This issue was resolved, and now a component can provide an atom feed via
GData protocol. However, some details need to be revised like:
- The necessity to support an uri like "/atomsvc" on get operations. (The
current implementation do not support this)
- The necessity to support the collection data-api. (The current
implementation do not support this)
When a SCA component is connected to other SCA component via binding.gdata,
in other words, Consumer and Provider are SCA components, the
*serviceType*attribute must be set with "sca" value. Values like "cl",
"blogger", or
"mail" are used when a SCA component is connected to a Google service.
It happens because I am having problems with authenticating a google account
via http request. So, I am using the GData API when I need to connect with a
Google service, letting http requests only for *serviceType* like "sca".
Maybe using only http requests, I could eliminate the necessity of the *
serviceType* attribute.
This JIRA contains the mentioned improvements:
https://issues.apache.org/jira/browse/TUSCANY-2494
About the 3 and 4, I think they are very important to have a usable
binding.gdata in real applications. Any suggestion here would be
appreciated.
Despite of these issues, the binding.gdata is working, and I think that I
can start the second phase of my project: developing the scenario example.
At the moment that new improvements were done on binding.gdata, the example
would be rebuilt to be compatible with the new features.
That's all for now,
Douglas
On Tue, Jun 24, 2008 at 11:16 AM, Douglas Leite <do...@gmail.com>wrote:
> 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 <lu...@gmail.com>
> 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 <lu...@gmail.com>
>> wrote:
>> > Re-sending as this might not have reached the mailing list.
>> >
>> > On Mon, Jun 23, 2008 at 11:33 AM, Luciano Resende <lu...@gmail.com>
>> 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 <do...@gmail.com>
>> 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 <do...@gmail.com>
>> 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 <
>> >>>> mike.edwards.inglenook@gmail.com> 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
>> >>>>>> <mi...@gmail.com> 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)
>
--
Douglas Siqueira Leite
Computer Science Master's degree student of University of Campinas
(Unicamp), Brazil
Re: [GSoC] [DISCUSS] Development of GData biding
Posted by Douglas Leite <do...@gmail.com>.
About the scenario example, I thought, initially, develop a list of free
software events, where the information about each event would be fed by XML
*feeds*. Hence, blog contents, documents, videos, and photos provided as
feeds, respectively, by Google Blog, Google Docs, YouTube, and Piscassa Web
Albums, or other source which is able to operate on GData protocol, would be
used as information to describe a given event.
The user would be able to create and edit events, as well as, associate
information that help to describe them.
Any modification in a given event at the application would reflect
automatically in the user's calendar defined at Google Calendar.
Anyone suggest me something different?
Any suggestions and criticism* *will be welcomed. :)
On Wed, Jul 30, 2008 at 1:43 AM, Douglas Leite <do...@gmail.com> wrote:
> During the mid-term evaluation I could realize the main issues related to
> the binding-gdata module that I am developing. They were:
>
> 1) The current state of binding.gdata only supports operations done with
> Google Calendar Service;
> 2) A component that uses a binding.gdata can only access Google services.
> There is still not a way to a component provide a GData service;
> 3) The authentication is done by passing the username and password
> information through the Service Component Definition Language (SCDL) file –
> there is still not any data encryption;
> 4) Operations to work with media types are not available yet.
>
> Because 1 and 2 implies directly on the correct behavior of the binding, I
> concentrated my efforts on resolving them.
>
> About 1:
> A new attribute was created to be used in SCDL file: *serviceType*. This
> attribute is used to specify the kind of service that the binding will
> handle with, like "cl" to Calendar, "blogger" to Blogger, or "mail" to
> GMail. So, we have something like this:
>
> *<binding.gdata uri="..." username="..." password="..."
> serviceType="cl"/> *
>
> About 2:
> This issue was resolved, and now a component can provide an atom feed via
> GData protocol. However, some details need to be revised like:
> - The necessity to support an uri like "/atomsvc" on get operations. (The
> current implementation do not support this)
> - The necessity to support the collection data-api. (The current
> implementation do not support this)
>
> When a SCA component is connected to other SCA component via binding.gdata,
> in other words, Consumer and Provider are SCA components, the *serviceType
> * attribute must be set with "sca" value. Values like "cl", "blogger", or
> "mail" are used when a SCA component is connected to a Google service.
>
> It happens because I am having problems with authenticating a google
> account via http request. So, I am using the GData API when I need to
> connect with a Google service, letting http requests only for *serviceType
> * like "sca". Maybe using only http requests, I could eliminate the
> necessity of the *serviceType* attribute.
>
> This JIRA contains the mentioned improvements:
> https://issues.apache.org/jira/browse/TUSCANY-2494
>
> About the 3 and 4, I think they are very important to have a usable
> binding.gdata in real applications. Any suggestion here would be
> appreciated.
>
> Despite of these issues, the binding.gdata is working, and I think that I
> can start the second phase of my project: developing the scenario example.
> At the moment that new improvements were done on binding.gdata, the example
> would be rebuilt to be compatible with the new features.
>
> That's all for now,
>
> Douglas
>
> On Tue, Jun 24, 2008 at 11:16 AM, Douglas Leite <do...@gmail.com>wrote:
>
>> 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 <lu...@gmail.com>
>> 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 <lu...@gmail.com>
>>> wrote:
>>> > Re-sending as this might not have reached the mailing list.
>>> >
>>> > On Mon, Jun 23, 2008 at 11:33 AM, Luciano Resende <
>>> luckbr1975@gmail.com> 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 <do...@gmail.com>
>>> 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 <do...@gmail.com>
>>> 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 <
>>> >>>> mike.edwards.inglenook@gmail.com> 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
>>> >>>>>> <mi...@gmail.com> 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)
>>
>
>
>
> --
> Douglas Siqueira Leite
> Computer Science Master's degree student of University of Campinas
> (Unicamp), Brazil
>
>
--
Douglas Siqueira Leite
Computer Science Master's degree student of University of Campinas
(Unicamp), Brazil