From photark-dev-return-1021-apmail-incubator-photark-dev-archive=incubator.apache.org@incubator.apache.org Mon Oct 11 19:17:35 2010 Return-Path: Delivered-To: apmail-incubator-photark-dev-archive@minotaur.apache.org Received: (qmail 7611 invoked from network); 11 Oct 2010 19:17:35 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 11 Oct 2010 19:17:35 -0000 Received: (qmail 40213 invoked by uid 500); 11 Oct 2010 19:17:35 -0000 Delivered-To: apmail-incubator-photark-dev-archive@incubator.apache.org Received: (qmail 40177 invoked by uid 500); 11 Oct 2010 19:17:35 -0000 Mailing-List: contact photark-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: photark-dev@incubator.apache.org Delivered-To: mailing list photark-dev@incubator.apache.org Received: (qmail 40165 invoked by uid 99); 11 Oct 2010 19:17:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 19:17:34 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.214.47] (HELO mail-bw0-f47.google.com) (209.85.214.47) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 19:17:30 +0000 Received: by bwz9 with SMTP id 9so873977bwz.6 for ; Mon, 11 Oct 2010 12:17:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.123.136 with SMTP id p8mr5361443bkr.148.1286824625741; Mon, 11 Oct 2010 12:17:05 -0700 (PDT) Received: by 10.204.84.32 with HTTP; Mon, 11 Oct 2010 12:17:05 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Oct 2010 00:47:05 +0530 Message-ID: Subject: Re: Subscription UI, was Re: [jira] Created: (PHOTARK-62) UI support to subscribe external albums From: Avdhesh Yadav To: photark-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=0016e6de17c8b4a20c04925c34ec --0016e6de17c8b4a20c04925c34ec Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 11, 2010 at 11:05 PM, Subash Chaturanga wrote: > On Mon, Oct 11, 2010 at 9:44 AM, Luciano Resende >wrote: > > > On Sun, Oct 10, 2010 at 4:20 PM, Luciano Resende > > 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 > > 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://twitter.com/lresende1975 > > http://lresende.blogspot.com/ > > > > > > -- > sk > > > Thanks > /subash > -- Avdhesh Yadav http://www.avdheshyadav.com http://twitter.com/yadavavdhesh --0016e6de17c8b4a20c04925c34ec--