incubator-photark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avdhesh Yadav <...@avdheshyadav.com>
Subject Re: Subscription UI, was Re: [jira] Created: (PHOTARK-62) UI support to subscribe external albums
Date Mon, 11 Oct 2010 19:17:05 GMT
On Mon, Oct 11, 2010 at 11:05 PM, Subash Chaturanga <subashsdm@gmail.com>wrote:

> On Mon, Oct 11, 2010 at 9:44 AM, Luciano Resende <luckbr1975@gmail.com
> >wrote:
>
> > On Sun, Oct 10, 2010 at 4:20 PM, Luciano Resende <luckbr1975@gmail.com>
> > wrote:
> > > On Sun, Oct 10, 2010 at 12:03 PM, Subash Chaturanga <
> subashsdm@gmail.com>
> > wrote:
> > >> Hi all ,
> > >>
> > >> On Thu, Oct 7, 2010 at 1:47 PM, Avdhesh Yadav <avd@avdheshyadav.com>
> > wrote:
> > >>
> > >>> check this thread.
> > >>>
> >
> http://www.mail-archive.com/photark-dev@incubator.apache.org/msg00784.html
> > >>
> > >>
> > >> The first patch i submitted stores each subscribed albums in a java
> > >> collection .So based on that, for the next step, I went through the
> > above
> > >> discussion and what i feel was to store the meta data
> > >> (location,name,description) of images in a JCR node. As, a JCR
>  property
> > can
> > >> hold multiple values, I think we can store each album as a property
> and
> > we
> > >> can have two nodes for flicker and picasa . So that when we want to
> show
> > >> them in gallery we can retrieve those data and on the fly create
> albums
> > and
> > >> show them in the gallery. I would like to know, if anything wrong with
> > this
> > >> approach or is there any better way to do this?
> > >>
> > >>
> > >>
> > >>
> > >
> > > I'd recommend following the same node structure as the "local JCR"
> > > albums, which the exception that when it's a subscription, the actual
> > > image is stored remotely and we only have it's URL.
> > >
> >
> > I was taking a look at the latest patch, and I'd have couple
> > suggestions to the Subscription UI:
> >
> > 1) Today for the upload ui, a user can choose a "New Album" or select
> > an existing album. How about we just create a new entry "New Remote
> > Album" for the Picasa or Flickr albums, and then show required fields
> > like : type (Picasa, Flickr, or anything new we might have) and then
> > the URL, username and password ?
> >
> > 2) Both upload.html and upload.js seems to have specific fields to
> > picasa_xxxx. This will not scale when we add support for different
> > types of remote albums. We should just make generic fields like
> > album_remote_url, album_remote_user, etc and use those independent of
> > the type of remote album that is being added to the gallery
> >
> > 3) It seems that subscription is actually working, but the ui is
> > acting a little weird as it seems to have succeeded adding the new
> > remote album, but it then stays on the same page with the fields all
> > populated as if a error had happened.
> >
> > 4) When I go back to albums view, it does not show any of the remote
> > albums. Is that part supposed to be working already ?
> >
>
>
> No , as a first step I just stored remote album meta data in a java
> collection.Didn't show them in gallery. As I hadn't a clear idea of,whether
> to store them in the repository or not.For that I have to change the method
> and store those meta data in the repository as the next step.And retrieve
> them and create albums and put them in gallery (as i feel) .
>

I am Thinking of one use case.Lets say user wants to subscribe a remote
album(e.g flicker).He adds a feedurl and clicks to subscribe button.Now we
have two options.

- One we immediately fetch the meta data from the feedurl(name,titile,
location) etc and save it to jcr repository.When user wants to view the
album we fetch remote album meta  data from our local JCR and display them.I
think performance wise it beneficial but we have to sync our repo
frequently.

- Another option is that we only save the feedurl to our jcr repository
initially and only fetch the meta data when user actually wants to view the
remote album.The benefit of this approach is that we do not need to
frequently sync our jcr.

Thoughts ?


>
> >
> >
> > I'll look in the backend part later on when I find more time :)
> >
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
> >
>
>
>
> --
> sk
>
>
> Thanks
> /subash
>



-- 
Avdhesh Yadav
http://www.avdheshyadav.com
http://twitter.com/yadavavdhesh

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