You are viewing a plain text version of this content. The canonical link for it is here.
Posted to photark-dev@incubator.apache.org by Umashanthi Pavalanathan <um...@gmail.com> on 2011/06/02 22:25:49 UTC
Re: Social API for PhotArk
Hi Henry,
On Tue, May 31, 2011 at 11:55 PM, Henry Saputra <he...@gmail.com>wrote:
> You can probably use and extend MediaItems[1] and Album[2] data model
> from OpenSocial specs to associate PhotArk image to a person/user.
>
Good point! I will look into them. Thanks!
>
> As for implementation, you can use Apache Shindig[3] as the base for
> your REST endpoints. It also has support for JSON-RPC for easy access
> from JavaScript.
>
Yes we are planning to integrate with Shindig and had few discussions on
another thread.
I will discuss about this further in the mailing list when I am done with
the first few phases of the project implementation.
Thanks,
~Umashanthi
>
> [1]
> http://opensocial-resources.googlecode.com/svn/spec/1.1/Social-Data.xml#MediaItem
> [2]
> http://opensocial-resources.googlecode.com/svn/spec/1.1/Social-Data.xml#Album
> [3] http://shindig.apache.org/
>
> - Henry
>
> On Tue, May 17, 2011 at 8:12 PM, Umashanthi Pavalanathan
> <um...@gmail.com> wrote:
> > Hi,
> >
> > On Tue, May 17, 2011 at 11:42 PM, Avdhesh Yadav <avd@avdheshyadav.com
> >wrote:
> >
> >> On Tue, May 17, 2011 at 11:45 AM, Umashanthi Pavalanathan <
> >> umashanthip@gmail.com> wrote:
> >>
> >> > Hi devs,
> >> >
> >> > As part of the GSoC project on 'Adding Social Features to PhotArk'
> [0],
> >> > currently I am working on building a social API for PhotArk.
> >> > The purpose of this is to enable support for social features in the
> >> PhotArk
> >> > back-end and to enable persisting social data. As discussed in an
> earlier
> >> > thread [1], I am planning to build the API based on the Open Social
> data
> >> > specification 1.0 [2]. It has two parts: Primary Social Data[3] and
> >> > Additional Social Data[4]. Supporting the primary data is essential. I
> >> > would
> >> > like to know the thoughts of you about supporting the additional
> social
> >> > data, considering its usage in PhortArk.
> >> >
> >> Can you please explain a bit more what are additional social data
> >>
> >
> > Additional Social Data objects are data objects that are contained within
> > other Social Data object. These do not stand alone.[0]
> > For eg:
> > The Person object has fields like name, address etc of type Name,
> Address.
> > The Name data object contains String type fields like firstname, lastname
> > etc and similarly the Address data object contains String fileds like
> > region, country etc.[1],[2]
> >
> >
> >
> >>
> >> > In my opinion, it will be fine to use String data type for fields like
> >> > Address, Organization, Name (firstname & lastname) etc. Your valuable
> >> > thoughts are much appreciated.
> >> >
> >> Yes I think String data type for the above fields are fine.
> >>
> >
> > +1. I also think the same since string type fields are enough to
> represent
> > social data in the context of PhotArk.
> >
> > Anyone having different thoughts?
> >
> >
> > [0]
> >
> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#rfc.section.3
> > [1]
> >
> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#Name
> > [2]
> >
> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#Address
> >
> >
> >
> > Thanks,
> > ~Umashanthi
> >
> >
> >> >
> >> >
> >> > [0]
> >> >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/PHOTARKxWIKI/Adding+Social+Features+to+PhotArk
> >> > [1]
> >> >
> >> >
> >>
> http://www.mail-archive.com/photark-dev@incubator.apache.org/index.html#01141
> >> > [2]
> >> >
> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml
> >> > [3]
> >> >
> >> >
> >>
> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#primary-social-data
> >> > [4]
> >> >
> >> >
> >>
> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#rfc.section.3
> >> >
> >> > Thanks,
> >> > ~Umashanthi
> >> >
> >>
> >>
> >>
> >> --
> >> Avdhesh Yadav
> >> http://www.avdheshyadav.com
> >> http://twitter.com/yadavavdhesh
> >>
> >
>
Re: Social API for PhotArk
Posted by Suhothayan Sriskandarajah <su...@gmail.com>.
On 28 June 2011 20:31, Luciano Resende <lu...@gmail.com> wrote:
> On Sat, Jun 25, 2011 at 1:00 PM, Henry Saputra <he...@gmail.com>
> wrote:
> > Luciano and PhotArk communities,
> >
> > I am proposing to use https://reviews.apache.org for our code review
> > since most of the code proposal for GSOC will be large so its hard to
> > do code review from raw patch.
> >
> > - Henry
> >
>
> I'm +0, it's useful and good to have a code review tool, but it
> shouldn't be mandatory.
> Part of the review (at least on my side) is apply the patch and see if
> things are working fine, then eclipse/git etc provide similar tools as
> well.
>
>
+1 for a review tools, this will always help to discuss and comment the
work. In my personal experience its easy to pin point the problems using
review tool and correct them, further this also reduces the effort and the
time of communication.
Regards
Suho
--
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: Social API for PhotArk
Posted by Luciano Resende <lu...@gmail.com>.
On Sat, Jun 25, 2011 at 1:00 PM, Henry Saputra <he...@gmail.com> wrote:
> Luciano and PhotArk communities,
>
> I am proposing to use https://reviews.apache.org for our code review
> since most of the code proposal for GSOC will be large so its hard to
> do code review from raw patch.
>
> - Henry
>
I'm +0, it's useful and good to have a code review tool, but it
shouldn't be mandatory.
Part of the review (at least on my side) is apply the patch and see if
things are working fine, then eclipse/git etc provide similar tools as
well.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Social API for PhotArk
Posted by Avdhesh Yadav <av...@avdheshyadav.com>.
On Sun, Jun 26, 2011 at 1:30 AM, Henry Saputra <he...@gmail.com>wrote:
> Luciano and PhotArk communities,
>
> I am proposing to use https://reviews.apache.org for our code review
> since most of the code proposal for GSOC will be large so its hard to
> do code review from raw patch.
>
+1
>
> - Henry
>
> On Sat, Jun 25, 2011 at 12:14 PM, Umashanthi Pavalanathan
> <um...@gmail.com> wrote:
> > Hi devs,
> >
> > I have completed the implementation of the Manager classes using JCR and
> > wrote test classes to cover basic operations as well.
> > I have attached the final patch to [0].
> >
> > Your feedback is highly appreciated.
> >
> > [0] ManagerImpl_implementations_v6.patch
> > https://issues.apache.org/jira/browse/PHOTARK-72
> >
> > Thanks,
> > ~Umashanthi
> >
> > On Wed, Jun 15, 2011 at 8:51 PM, Umashanthi Pavalanathan <
> > umashanthip@gmail.com> wrote:
> >
> >> Hi devs,
> >>
> >> I have implemented the PersonManager and RelationshipManager interfaces
> >> using JCR and submitted a patch [0]. I used JCR Node's STRING properties
> to
> >> implement the concept of relationship between two user profiles. I have
> >> written two test classes to cover the basic functionalities of the
> methods
> >> and was able to run them with success.
> >>
> >> I would like to get your feedback on this implementation.
> >>
> >> [0] ManagerImpl_implementations_v4.patch
> >> https://issues.apache.org/jira/browse/PHOTARK-72
> >>
> >>
> >> <https://issues.apache.org/jira/browse/PHOTARK-72>Thanks,
> >> ~Umashanthi
> >>
> >>
> >> On Sat, Jun 4, 2011 at 11:24 AM, Umashanthi Pavalanathan <
> >> umashanthip@gmail.com> wrote:
> >>
> >>>
> >>>
> >>> On Sat, Jun 4, 2011 at 6:28 AM, Luciano Resende <luckbr1975@gmail.com
> >wrote:
> >>>
> >>>> On Fri, Jun 3, 2011 at 4:48 PM, Umashanthi Pavalanathan
> >>>> <um...@gmail.com> wrote:
> >>>> > Hi devs,
> >>>> > I am in the process of adding persistence support to the social API
> >>>> using
> >>>> > JCR.
> >>>> > For that first we have to decide on the node structure. I have come
> up
> >>>> with
> >>>> > two options (please refer attached image).
> >>>> > In option-1, for each username, we have
> >>>> profile,activity,appdata,messages
> >>>> > child nodes.
> >>>> > In option-2, under nodes people,activity,appdata,messages, we have
> >>>> child
> >>>> > node for each user.
> >>>> > Referring to the two options, which is more suitable in your
> opinion?
> >>>> >
> >>>> > Thanks,
> >>>> > ~Umashanthi
> >>>>
> >>>> I think if we have a good understanding of the data access pattern, it
> >>>> can help us decide which structure to use. For example, if we would
> >>>> mostly show list of activities by user, and all other data by user,
> >>>> I'd go with option 1.
> >>>>
> >>>
> >>> Yes; as I understood we would mostly access data by user and my +1 for
> the
> >>> option-1.
> >>>
> >>>
> >>> Thanks,
> >>> ~Umashanthi
> >>>
> >>>
> >>>
> >>>>
> >>>> --
> >>>>
> >>>> Luciano Resende
> >>>> http://people.apache.org/~lresende
> >>>> http://twitter.com/lresende1975
> >>>> http://lresende.blogspot.com/
> >>>>
> >>>
> >>>
> >>
> >
>
--
Avdhesh Yadav
http://www.avdheshyadav.com
http://twitter.com/yadavavdhesh
Re: Social API for PhotArk
Posted by Henry Saputra <he...@gmail.com>.
Luciano and PhotArk communities,
I am proposing to use https://reviews.apache.org for our code review
since most of the code proposal for GSOC will be large so its hard to
do code review from raw patch.
- Henry
On Sat, Jun 25, 2011 at 12:14 PM, Umashanthi Pavalanathan
<um...@gmail.com> wrote:
> Hi devs,
>
> I have completed the implementation of the Manager classes using JCR and
> wrote test classes to cover basic operations as well.
> I have attached the final patch to [0].
>
> Your feedback is highly appreciated.
>
> [0] ManagerImpl_implementations_v6.patch
> https://issues.apache.org/jira/browse/PHOTARK-72
>
> Thanks,
> ~Umashanthi
>
> On Wed, Jun 15, 2011 at 8:51 PM, Umashanthi Pavalanathan <
> umashanthip@gmail.com> wrote:
>
>> Hi devs,
>>
>> I have implemented the PersonManager and RelationshipManager interfaces
>> using JCR and submitted a patch [0]. I used JCR Node's STRING properties to
>> implement the concept of relationship between two user profiles. I have
>> written two test classes to cover the basic functionalities of the methods
>> and was able to run them with success.
>>
>> I would like to get your feedback on this implementation.
>>
>> [0] ManagerImpl_implementations_v4.patch
>> https://issues.apache.org/jira/browse/PHOTARK-72
>>
>>
>> <https://issues.apache.org/jira/browse/PHOTARK-72>Thanks,
>> ~Umashanthi
>>
>>
>> On Sat, Jun 4, 2011 at 11:24 AM, Umashanthi Pavalanathan <
>> umashanthip@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, Jun 4, 2011 at 6:28 AM, Luciano Resende <lu...@gmail.com>wrote:
>>>
>>>> On Fri, Jun 3, 2011 at 4:48 PM, Umashanthi Pavalanathan
>>>> <um...@gmail.com> wrote:
>>>> > Hi devs,
>>>> > I am in the process of adding persistence support to the social API
>>>> using
>>>> > JCR.
>>>> > For that first we have to decide on the node structure. I have come up
>>>> with
>>>> > two options (please refer attached image).
>>>> > In option-1, for each username, we have
>>>> profile,activity,appdata,messages
>>>> > child nodes.
>>>> > In option-2, under nodes people,activity,appdata,messages, we have
>>>> child
>>>> > node for each user.
>>>> > Referring to the two options, which is more suitable in your opinion?
>>>> >
>>>> > Thanks,
>>>> > ~Umashanthi
>>>>
>>>> I think if we have a good understanding of the data access pattern, it
>>>> can help us decide which structure to use. For example, if we would
>>>> mostly show list of activities by user, and all other data by user,
>>>> I'd go with option 1.
>>>>
>>>
>>> Yes; as I understood we would mostly access data by user and my +1 for the
>>> option-1.
>>>
>>>
>>> Thanks,
>>> ~Umashanthi
>>>
>>>
>>>
>>>>
>>>> --
>>>>
>>>> Luciano Resende
>>>> http://people.apache.org/~lresende
>>>> http://twitter.com/lresende1975
>>>> http://lresende.blogspot.com/
>>>>
>>>
>>>
>>
>
Re: Social API for PhotArk
Posted by Umashanthi Pavalanathan <um...@gmail.com>.
Hi devs,
I have completed the implementation of the Manager classes using JCR and
wrote test classes to cover basic operations as well.
I have attached the final patch to [0].
Your feedback is highly appreciated.
[0] ManagerImpl_implementations_v6.patch
https://issues.apache.org/jira/browse/PHOTARK-72
Thanks,
~Umashanthi
On Wed, Jun 15, 2011 at 8:51 PM, Umashanthi Pavalanathan <
umashanthip@gmail.com> wrote:
> Hi devs,
>
> I have implemented the PersonManager and RelationshipManager interfaces
> using JCR and submitted a patch [0]. I used JCR Node's STRING properties to
> implement the concept of relationship between two user profiles. I have
> written two test classes to cover the basic functionalities of the methods
> and was able to run them with success.
>
> I would like to get your feedback on this implementation.
>
> [0] ManagerImpl_implementations_v4.patch
> https://issues.apache.org/jira/browse/PHOTARK-72
>
>
> <https://issues.apache.org/jira/browse/PHOTARK-72>Thanks,
> ~Umashanthi
>
>
> On Sat, Jun 4, 2011 at 11:24 AM, Umashanthi Pavalanathan <
> umashanthip@gmail.com> wrote:
>
>>
>>
>> On Sat, Jun 4, 2011 at 6:28 AM, Luciano Resende <lu...@gmail.com>wrote:
>>
>>> On Fri, Jun 3, 2011 at 4:48 PM, Umashanthi Pavalanathan
>>> <um...@gmail.com> wrote:
>>> > Hi devs,
>>> > I am in the process of adding persistence support to the social API
>>> using
>>> > JCR.
>>> > For that first we have to decide on the node structure. I have come up
>>> with
>>> > two options (please refer attached image).
>>> > In option-1, for each username, we have
>>> profile,activity,appdata,messages
>>> > child nodes.
>>> > In option-2, under nodes people,activity,appdata,messages, we have
>>> child
>>> > node for each user.
>>> > Referring to the two options, which is more suitable in your opinion?
>>> >
>>> > Thanks,
>>> > ~Umashanthi
>>>
>>> I think if we have a good understanding of the data access pattern, it
>>> can help us decide which structure to use. For example, if we would
>>> mostly show list of activities by user, and all other data by user,
>>> I'd go with option 1.
>>>
>>
>> Yes; as I understood we would mostly access data by user and my +1 for the
>> option-1.
>>
>>
>> Thanks,
>> ~Umashanthi
>>
>>
>>
>>>
>>> --
>>>
>>> Luciano Resende
>>> http://people.apache.org/~lresende
>>> http://twitter.com/lresende1975
>>> http://lresende.blogspot.com/
>>>
>>
>>
>
Re: Social API for PhotArk
Posted by Umashanthi Pavalanathan <um...@gmail.com>.
Hi devs,
I have implemented the PersonManager and RelationshipManager interfaces
using JCR and submitted a patch [0]. I used JCR Node's STRING properties to
implement the concept of relationship between two user profiles. I have
written two test classes to cover the basic functionalities of the methods
and was able to run them with success.
I would like to get your feedback on this implementation.
[0] ManagerImpl_implementations_v4.patch
https://issues.apache.org/jira/browse/PHOTARK-72
<https://issues.apache.org/jira/browse/PHOTARK-72>Thanks,
~Umashanthi
On Sat, Jun 4, 2011 at 11:24 AM, Umashanthi Pavalanathan <
umashanthip@gmail.com> wrote:
>
>
> On Sat, Jun 4, 2011 at 6:28 AM, Luciano Resende <lu...@gmail.com>wrote:
>
>> On Fri, Jun 3, 2011 at 4:48 PM, Umashanthi Pavalanathan
>> <um...@gmail.com> wrote:
>> > Hi devs,
>> > I am in the process of adding persistence support to the social API
>> using
>> > JCR.
>> > For that first we have to decide on the node structure. I have come up
>> with
>> > two options (please refer attached image).
>> > In option-1, for each username, we have
>> profile,activity,appdata,messages
>> > child nodes.
>> > In option-2, under nodes people,activity,appdata,messages, we have child
>> > node for each user.
>> > Referring to the two options, which is more suitable in your opinion?
>> >
>> > Thanks,
>> > ~Umashanthi
>>
>> I think if we have a good understanding of the data access pattern, it
>> can help us decide which structure to use. For example, if we would
>> mostly show list of activities by user, and all other data by user,
>> I'd go with option 1.
>>
>
> Yes; as I understood we would mostly access data by user and my +1 for the
> option-1.
>
>
> Thanks,
> ~Umashanthi
>
>
>
>>
>> --
>>
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>>
>
>
Re: Social API for PhotArk
Posted by Umashanthi Pavalanathan <um...@gmail.com>.
On Sat, Jun 4, 2011 at 6:28 AM, Luciano Resende <lu...@gmail.com>wrote:
> On Fri, Jun 3, 2011 at 4:48 PM, Umashanthi Pavalanathan
> <um...@gmail.com> wrote:
> > Hi devs,
> > I am in the process of adding persistence support to the social API using
> > JCR.
> > For that first we have to decide on the node structure. I have come up
> with
> > two options (please refer attached image).
> > In option-1, for each username, we have profile,activity,appdata,messages
> > child nodes.
> > In option-2, under nodes people,activity,appdata,messages, we have child
> > node for each user.
> > Referring to the two options, which is more suitable in your opinion?
> >
> > Thanks,
> > ~Umashanthi
>
> I think if we have a good understanding of the data access pattern, it
> can help us decide which structure to use. For example, if we would
> mostly show list of activities by user, and all other data by user,
> I'd go with option 1.
>
Yes; as I understood we would mostly access data by user and my +1 for the
option-1.
Thanks,
~Umashanthi
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: Social API for PhotArk
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Jun 3, 2011 at 4:48 PM, Umashanthi Pavalanathan
<um...@gmail.com> wrote:
> Hi devs,
> I am in the process of adding persistence support to the social API using
> JCR.
> For that first we have to decide on the node structure. I have come up with
> two options (please refer attached image).
> In option-1, for each username, we have profile,activity,appdata,messages
> child nodes.
> In option-2, under nodes people,activity,appdata,messages, we have child
> node for each user.
> Referring to the two options, which is more suitable in your opinion?
>
> Thanks,
> ~Umashanthi
I think if we have a good understanding of the data access pattern, it
can help us decide which structure to use. For example, if we would
mostly show list of activities by user, and all other data by user,
I'd go with option 1.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Social API for PhotArk
Posted by Umashanthi Pavalanathan <um...@gmail.com>.
Hi devs,
I am in the process of adding persistence support to the social API using
JCR.
For that first we have to decide on the node structure. I have come up with
two options (please refer attached image).
In option-1, for each username, we have profile,activity,appdata,messages
child nodes.
In option-2, under nodes people,activity,appdata,messages, we have child
node for each user.
Referring to the two options, which is more suitable in your opinion?
Thanks,
~Umashanthi
On Fri, Jun 3, 2011 at 3:55 AM, Umashanthi Pavalanathan <
umashanthip@gmail.com> wrote:
> Hi Henry,
>
> On Tue, May 31, 2011 at 11:55 PM, Henry Saputra <he...@gmail.com>wrote:
>
>> You can probably use and extend MediaItems[1] and Album[2] data model
>> from OpenSocial specs to associate PhotArk image to a person/user.
>>
>
> Good point! I will look into them. Thanks!
>
>
>>
>> As for implementation, you can use Apache Shindig[3] as the base for
>> your REST endpoints. It also has support for JSON-RPC for easy access
>> from JavaScript.
>>
>
> Yes we are planning to integrate with Shindig and had few discussions on
> another thread.
> I will discuss about this further in the mailing list when I am done with
> the first few phases of the project implementation.
>
> Thanks,
> ~Umashanthi
>
>
>>
>> [1]
>> http://opensocial-resources.googlecode.com/svn/spec/1.1/Social-Data.xml#MediaItem
>> [2]
>> http://opensocial-resources.googlecode.com/svn/spec/1.1/Social-Data.xml#Album
>> [3] http://shindig.apache.org/
>>
>> - Henry
>>
>> On Tue, May 17, 2011 at 8:12 PM, Umashanthi Pavalanathan
>> <um...@gmail.com> wrote:
>> > Hi,
>> >
>> > On Tue, May 17, 2011 at 11:42 PM, Avdhesh Yadav <avd@avdheshyadav.com
>> >wrote:
>> >
>> >> On Tue, May 17, 2011 at 11:45 AM, Umashanthi Pavalanathan <
>> >> umashanthip@gmail.com> wrote:
>> >>
>> >> > Hi devs,
>> >> >
>> >> > As part of the GSoC project on 'Adding Social Features to PhotArk'
>> [0],
>> >> > currently I am working on building a social API for PhotArk.
>> >> > The purpose of this is to enable support for social features in the
>> >> PhotArk
>> >> > back-end and to enable persisting social data. As discussed in an
>> earlier
>> >> > thread [1], I am planning to build the API based on the Open Social
>> data
>> >> > specification 1.0 [2]. It has two parts: Primary Social Data[3] and
>> >> > Additional Social Data[4]. Supporting the primary data is essential.
>> I
>> >> > would
>> >> > like to know the thoughts of you about supporting the additional
>> social
>> >> > data, considering its usage in PhortArk.
>> >> >
>> >> Can you please explain a bit more what are additional social data
>> >>
>> >
>> > Additional Social Data objects are data objects that are contained
>> within
>> > other Social Data object. These do not stand alone.[0]
>> > For eg:
>> > The Person object has fields like name, address etc of type Name,
>> Address.
>> > The Name data object contains String type fields like firstname,
>> lastname
>> > etc and similarly the Address data object contains String fileds like
>> > region, country etc.[1],[2]
>> >
>> >
>> >
>> >>
>> >> > In my opinion, it will be fine to use String data type for fields
>> like
>> >> > Address, Organization, Name (firstname & lastname) etc. Your valuable
>> >> > thoughts are much appreciated.
>> >> >
>> >> Yes I think String data type for the above fields are fine.
>> >>
>> >
>> > +1. I also think the same since string type fields are enough to
>> represent
>> > social data in the context of PhotArk.
>> >
>> > Anyone having different thoughts?
>> >
>> >
>> > [0]
>> >
>> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#rfc.section.3
>> > [1]
>> >
>> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#Name
>> > [2]
>> >
>> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#Address
>> >
>> >
>> >
>> > Thanks,
>> > ~Umashanthi
>> >
>> >
>> >> >
>> >> >
>> >> > [0]
>> >> >
>> >> >
>> >>
>> https://cwiki.apache.org/confluence/display/PHOTARKxWIKI/Adding+Social+Features+to+PhotArk
>> >> > [1]
>> >> >
>> >> >
>> >>
>> http://www.mail-archive.com/photark-dev@incubator.apache.org/index.html#01141
>> >> > [2]
>> >> >
>> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml
>> >> > [3]
>> >> >
>> >> >
>> >>
>> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#primary-social-data
>> >> > [4]
>> >> >
>> >> >
>> >>
>> http://opensocial-resources.googlecode.com/svn/spec/1.0/Social-Data.xml#rfc.section.3
>> >> >
>> >> > Thanks,
>> >> > ~Umashanthi
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Avdhesh Yadav
>> >> http://www.avdheshyadav.com
>> >> http://twitter.com/yadavavdhesh
>> >>
>> >
>>
>
>