From photark-dev-return-1022-apmail-incubator-photark-dev-archive=incubator.apache.org@incubator.apache.org Mon Oct 11 19:31:23 2010 Return-Path: Delivered-To: apmail-incubator-photark-dev-archive@minotaur.apache.org Received: (qmail 10161 invoked from network); 11 Oct 2010 19:31:23 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 11 Oct 2010 19:31:23 -0000 Received: (qmail 52733 invoked by uid 500); 11 Oct 2010 19:31:23 -0000 Delivered-To: apmail-incubator-photark-dev-archive@incubator.apache.org Received: (qmail 52710 invoked by uid 500); 11 Oct 2010 19:31:23 -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 52702 invoked by uid 99); 11 Oct 2010 19:31:23 -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 19:31:23 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,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 luckbr1975@gmail.com designates 209.85.214.175 as permitted sender) Received: from [209.85.214.175] (HELO mail-iw0-f175.google.com) (209.85.214.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 19:31:17 +0000 Received: by iwn2 with SMTP id 2so63192iwn.6 for ; Mon, 11 Oct 2010 12:30:56 -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 :content-transfer-encoding; bh=/ZSUr5ZeeD8y1H6+c1Tdv3JwatUYx0FDnrAz/xAirV8=; b=GnarU7NeigeagA7Fh+ccWPW+w69A7IdNcpDcKZu5z2ixE87ftardtyJF2wsvXsMkQM V0aCrtJqk9pEiWHFOGqA4jAAowWYlg2prONBdyTY3yIFNq5uklPfZ2/4ZAFcM+8pYJX5 /quMi0SmFMJqYT/xV7LitHQQJrxO7O3VDZ0Us= 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:content-transfer-encoding; b=l1AW1U4jMQoTFlBGOZ91vRFJsVsKH2gQZbG2ZOJU08vwzocrdThKWC6AhVtx/hjC4M F2kyFB4BEITGDLJsLlrFI3rITEpfCNQnOoOX63oEPeYkh/c0dwOhjhfAs1gyVsCICBPx jedQX9kWrxvLshkwovyB7eq1tGhBN4n9P9Jzs= MIME-Version: 1.0 Received: by 10.231.149.3 with SMTP id r3mr4929751ibv.109.1286825455992; Mon, 11 Oct 2010 12:30:55 -0700 (PDT) Received: by 10.231.115.155 with HTTP; Mon, 11 Oct 2010 12:30:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Oct 2010 12:30:55 -0700 Message-ID: Subject: Re: Subscription UI, was Re: [jira] Created: (PHOTARK-62) UI support to subscribe external albums From: Luciano Resende To: photark-dev@incubator.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Oct 11, 2010 at 12:17 PM, Avdhesh Yadav wrot= e: > > 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 w= e > 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 =C2=A0data from our local JCR and displa= y 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 t= he > remote album.The benefit of this approach is that we do not need to > frequently sync our jcr. > > Thoughts ? I'd say that we would want to let the user specify title, and the URL of the remote album. As for storing stuff locally in our JCR repo and fetching it all the time, we should have metadata stored locally to allow searching. As for how we go about approaching this, I'd recommend that we start with retrieving it from the remote site and storing in a local cache (e.g a map) inside of a @Scope("COMPOSITE") component, and then on a second phase, we would add the full blow sync and test searching, etc. Thoughts ? --=20 Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/