incubator-photark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suhothayan Sriskandarajah <suhotha...@gmail.com>
Subject Re: Next PhotArk Release
Date Sun, 29 Aug 2010 16:54:51 GMT
On 29 August 2010 12:25, Avdhesh Yadav <avd@avdheshyadav.com> wrote:

> Thats fine
>
> So next week i will look into the issue Photark-56 and in between if we
> could get Luis to add album subscription funtionlaty to the the trunk.After
> that we would start working on the next release.
>
+1
I also try to do some improvements by changing 'editing albums description'
and deleting images to JSON RPC based then the current rest based
implantation. so all the functionalities will be unified

suho

>
> On Sun, Aug 29, 2010 at 12:17 PM, Luciano Resende <luckbr1975@gmail.com
> >wrote:
>
> > On Sat, Aug 28, 2010 at 11:22 PM, Avdhesh Yadav <avd@avdheshyadav.com>
> > wrote:
> > > As we Have discussions earlier that REST based Photark gallery would be
> > our
> > > main focus. I think we should port all the access-control and album
> > > functionality to the REST branch and then merge it with the trunk.
> > >
> > > thoughts ?
> > >
> >
> > I really wanted to avoid rushing with the REST branch just to get a
> > release out. My preference would be to make the rest branch stable
> > with regarding Gallery/Album operations, then merge/port
> > access-control and search functionality, and then merge UI (or merge
> > it back to trunk). To make things right, this would involve lots of
> > discussion around the design, particularly for access-control
> > functionality and it would delay this release, so I'd suggest leave
> > this for a next release.
> >
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende><
> http://people.apache.org/%7Elresende>
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
> >
>
>
>
> --
> Avdhesh Yadav
> http://www.avdheshyadav.com
> http://twitter.com/yadavavdhesh
>

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