incubator-photark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Umashanthi Pavalanathan <umashant...@gmail.com>
Subject Re: Making PhotArk More Social
Date Sat, 05 Feb 2011 06:48:49 GMT
Hi Luciano & all,

I've come up with a draft of a SocialAPI for PhotArk and documented here:
https://docs.google.com/document/pub?id=1XfDqRsvR6DT1PrXHuJ7d47PDP2tQXFpU-bV-1Aj3BsE

I would like to get your valuable suggestions & thoughts on this, please...


Thanks,
~Umashanthi


On Thu, Feb 3, 2011 at 8:16 AM, Umashanthi Pavalanathan <
umashanthip@gmail.com> wrote:

>
>
> On Thu, Jan 27, 2011 at 4:43 AM, Umashanthi Pavalanathan <
> umashanthip@gmail.com> wrote:
>
>> Hi,
>>
>> On Mon, Jan 24, 2011 at 11:55 AM, Umashanthi Pavalanathan <
>> umashanthip@gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Jan 24, 2011 at 11:31 AM, Luciano Resende <luckbr1975@gmail.com>wrote:
>>>
>>>> On Sun, Jan 23, 2011 at 9:21 PM, Umashanthi Pavalanathan
>>>> <umashanthip@gmail.com> wrote:
>>>> >> We have been working on a new REST api a branch, and maybe
>>>> >> we could start prototyping some OpenSocial integration on top of
>>>> that.
>>>> >>  Your help and contributions would be appreciated.
>>>> >>
>>>> >
>>>> > I will start by looking at the REST api branch and the code base.
>>>> >
>>>> >
>>>>
>>>> If we use a Open Social framework such as Shindig, does it require a
>>>> RDBMS as it's persistence repository (e.g Derby, MySQL)... or can it
>>>> be integrated with a JCR repository ?
>>>>
>>>
>>> Well. Simple answer is, the integration is independent of the persistence
>>> mechanism. No such requirements from Shindig and we can use the JCR
>>> repository or any other database.
>>>
>>> Small explanation:
>>> Apache Shindig[1] provides the following Service interfaces, for the
>>> basic OpenSocial concepts[3]:
>>> Person Service
>>> Activity Service
>>> AppData Service
>>> Message Service
>>> and handlers for each of them. When integrating with Shindig, what we
>>> have to do is to write our custom services and handlers (if required)
>>> implementing the Shindig services and bind them using guice. So, Shindig
>>> doesn't handle the back-end persistence. We can use our own data storage
>>> mechanisms and customize the Services provided by Shindig.
>>>
>>
>> As the first step to integrate open social features into PhotArk using
>> Apache Shindig, it is required to build a social network back-end with
>> PhotArk and later it can be connected to the Shindig's Service Provider
>> Interfaces (SPI) [1].
>>
>> In my opinion it is better to design an API for this social network
>> back-end, so that it can easily be expanded and new requirements in future
>> open social specifications can be incorporated easily. Basically there
>> should the following concepts in the API:
>> 1. Person (user)
>> 2. User Profiles
>> 3. Relationship (eg: friends)
>> 4. User Groups
>> 5. Activity (user activities including uploading new photos, creating new
>> albums, commenting, tagging etc)
>> 6. AppData
>> 7. Messages
>>
>> Shindig Java docs for the package org.apache.shindig.social  and it's sub
>> packages available at [2] would give more idea of such API.
>> If you agree with this approach, I would like to start building a Social
>> API for PhotArk and discuss more here.
>>
>
> Any thoughts regarding this idea of creating an API for the social
> features?
>
> Would like to hear your thoughts...
>
> Thanks,
> ~Umashanthi
>
>
>
>>
>> Thoughts please?
>>
>> [1] http://www.opensocial.org/page/building-an-opensocial
>> [2] http://shindig.apache.org/shindig-1.1.x/apidocs/index.html
>>
>> Thanks,
>> ~Umashanthi
>>
>>
>>
>>>
>>>
>>> [1] http://shindig.apache.org/
>>> [2] http://shindig.apache.org/overview.html
>>>  [3]
>>> http://svn.apache.org/repos/asf/shindig/trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/
>>>
>>>
>>> Thanks,
>>> ~Umashanthi
>>>
>>>
>>>
>>>> --
>>>> Luciano Resende
>>>> http://people.apache.org/~lresende
>>>> http://twitter.com/lresende1975
>>>> http://lresende.blogspot.com/
>>>>
>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message