From photark-dev-return-1025-apmail-incubator-photark-dev-archive=incubator.apache.org@incubator.apache.org Mon Oct 11 20:04:51 2010 Return-Path: Delivered-To: apmail-incubator-photark-dev-archive@minotaur.apache.org Received: (qmail 18072 invoked from network); 11 Oct 2010 20:04:51 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 11 Oct 2010 20:04:51 -0000 Received: (qmail 97902 invoked by uid 500); 11 Oct 2010 20:04:51 -0000 Delivered-To: apmail-incubator-photark-dev-archive@incubator.apache.org Received: (qmail 97875 invoked by uid 500); 11 Oct 2010 20:04:51 -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 97867 invoked by uid 99); 11 Oct 2010 20:04:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 20:04:51 +0000 X-ASF-Spam-Status: No, hits=4.7 required=10.0 tests=FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of subashsdm@gmail.com designates 209.85.216.182 as permitted sender) Received: from [209.85.216.182] (HELO mail-qy0-f182.google.com) (209.85.216.182) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 20:04:45 +0000 Received: by qyk30 with SMTP id 30so402325qyk.6 for ; Mon, 11 Oct 2010 13:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=xxNdhDo7mICNYA3iHeVovQY5YslnM4Wzo1H9KT6os9w=; b=sLucLJUK4jmvfnMSGnDHsL2HYeKvBknfJnur/6GQ8Z7hWhHoKT427onR1kRQIGL0Ex 3G+OSG6TG2MrisuWXBaFiCHGtNMFFmsxnnqXjP0EknRht10v4ADUfraXI+F4hx26vfrU j9fdtMVs8J1P52DUbzqpJgKmwXfVJhhDpD9x8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=IdNDO3+SctmEp8qtiT0XB1fbxrWem5jhrALBhhhgbPjl767yC7N9Cnuwbj/4bXsi34 z/yKHhWhDco62YPQcL0hU+Df8RvKOd9eNPgx0FyR6HlkLiomgzkpv+diYE5txr+aDGJe sWFX3R2v+0k8s54VhaaaKGoPTl5AG2t2En+/I= MIME-Version: 1.0 Received: by 10.224.73.131 with SMTP id q3mr3611102qaj.3.1286827456087; Mon, 11 Oct 2010 13:04:16 -0700 (PDT) Received: by 10.229.85.72 with HTTP; Mon, 11 Oct 2010 13:04:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Oct 2010 01:34:16 +0530 Message-ID: Subject: Re: Subscription UI, was Re: [jira] Created: (PHOTARK-62) UI support to subscribe external albums From: Subash Chaturanga To: photark-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=0015175cb96668473704925cdd7c X-Virus-Checked: Checked by ClamAV on apache.org --0015175cb96668473704925cdd7c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 12, 2010 at 12:47 AM, Avdhesh Yadav wrote: > 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 ? > > Say I subscribe to album "A1" and view the album and logout. After I come back (I think i must see the subscribed album in the gallery(at least the name of the album), in a separate partition called subscribed albums).And with each album name, we can provide a refresh (or view) button or link which reload all current images of the particular album based on the feed url . +1 for option2 as we don't need frequent sync. But as we want search option to find subscribed albums or images we can still store meta data in the repository and in every refresh we can update the node (album) meta data while album viewing part is done as previously said. > > > > > > > > > > > > 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 > Regards /subash --0015175cb96668473704925cdd7c--