From: Bharat M. <bh...@me...> - 2010-01-18 01:57:28
|
Too late, we're already building a Gallery specific REST interface. The good news is that this has forced a few key abstractions (like model based validation) that will make other APIs dead simple. So building a Flickr version shouldn't be too hard at all (provided we can get the various concepts to mesh). Serguei Dosyukov wrote: > -1 > > http://codex.gallery2.org/Gallery3:API says > > "REST component of Gallery 3 REST component of Gallery 3 ... was never > finished, and will be removed from Gallery 3 ... We're building a new API > based on the [Flickr API]." > > Good. Let's do it... why? Because people do know and use FAPI, another > custom API for G3 would only delay integration of G3 within other 3rd party > solutions. If you build G3 specific API and then wait for someone create API > for Flickr and maintain it after, this may never happen. > Flickr being more widely used I think already went the road of making it as > generic as possible... why reinvent the wheel? > If there is something in FAPI which is missing then make FAPI extension > specific to G3, but still make it compatible with the core. > So my vote for FAPI first and then FAPI+ as extension if necessary... > > -----Original Message----- > From: Bharat Mediratta [mailto:bh...@me...] > Sent: Friday, November 27, 2009 4:39 PM > To: Tim Almdal > Cc: gal...@li... > Subject: Re: [Gallery-devel] Fwd: Re: [Gallery-core] Gallery remote API > early thoughts > > > I propose that we create a G3 specific API such that we don't have to > make any weird sacrifices in the main API code. Then we create a Flickr > compatible interface that wraps our interface and make any Flickr > specific tradeoffs there. Best of both worlds, and probably not that > much additional code. > > Tim Almdal wrote: >> Initial thoughts on remote API... custom vs Flickr compatible >> >> ----- Original Message ----- >> From: Tim Almdal <tna...@sh...> >> Date: Friday, November 27, 2009 1:30 pm >> Subject: Re: [Gallery-core] Gallery remote API early thoughts >> To: Gallery Project Core Team discussion list >> <gal...@li...> >> >> > I guess I'm 100% opposed to making our API compatible to Flickr. >> > >> > I believe that there are too many dissimilarities between the >> > intent of Flickr and Gallery3's intent. In my experience trying >> > to warp an API meant for one system doesn't work out well. You >> > end up spending a lot of time and effort hacking the new target >> > system to make it look like the old one. >> > >> > When I look down the list of "Notable Details" in the original >> > API discussion on http://codex.gallery2.org/Gallery3:API a >> > significant portion of those are places were we are going to >> > either hack the API or have to hack Gallery3 in order to make >> > things work. Once we change how the api works we are no longer >> > compatible and might as well just start off with a clean slate. >> > >> > We have to bend out standard url processing to handle the >> > flicker API urls. >> > The Flickr API has a lot of stuff in that doesn't apply to us >> > and we need to spend time insuring that there is a sane response >> > for things we don't support. >> > Photosets are not albums, so we have to kludge up a response to that. >> > The original API discussion said "our login process will have to >> > work differently". So now our API could be incompatible >> > depending on how we implement login. >> > The original discussion indicated that most "API entry points >> > are coded into libraries". If that is truly the case, we are >> > getting minimal advantage of prebuilt Flickr libraries and would >> > require someone to create modified versions of any libraries >> > that have hard coded endpoints. Might as well have someone code >> > new clients to our API. >> > Their API has tight integration with tags, ours should allow >> > tags to be added, but we don't have the same dependence on tags >> > In my opinion, as long as the interface is simple, clean and >> > easy to build then I think we are further ahead in creating our >> > own then trying morph the Flicker interface into something its not. >> > >> > Tim >> > >> > ----- Original Message ----- >> > From: Chris Kelly <ck...@ck...> >> > Date: Friday, November 27, 2009 12:04 pm >> > Subject: Re: [Gallery-core] Gallery remote API early thoughts >> > To: Gallery Project Core Team discussion list <gallery- >> > co...@li...> >> > > There are two approaches we can take here: >> > > >> > > 1. Use the Flickr API as a model of making a quality remote API >> > > >> > > 2. Make an API that is compatible with the Flickr API which >> > gets >> > > us free compatibility with a _lot_ of clients. >> > > >> > > What you're describing is #1 and I'm a fan of #2. While >> > > it's fine to not verify an API key, I think the field should >> > > definitely be in the API requests and can just be ignored for >> > > non-Flickr-based clients. >> > > >> > > The rest sounds good! >> > > >> > > -Chris >> > > >> > > On Nov 27, 2009, at 1:56 PM, Tim Almdal wrote: >> > > > These are some earlier thoughts about where I want to take >> > the >> > > remote API based on my reviewing the Flickr API. Just >> > > wanted to get some internal feedback before I flesh it out to >> > > far and share it on the -devel list. >> > > > >> > > > With Gallery3, there is a need for a simplified and >> > > standardized remote API. Originally, some of the core >> > > controllers in Gallery3 were built as a RESTful API. >> > > Several issues resulted from this approach, mainly it added >> > > complexity and was not applied consistently. >> > > > >> > > > Early discussions suggested using the Flicker API as it a >> > well >> > > defined, popular interface. The Flickr API consists of a set >> > of >> > > callable methods, and some API endpoints. To perform an >> > > action using the Flickr API, you need to select a calling >> > > convention (REST, SOAP, XML-RPC), send a request to its >> > endpoint >> > > specifying a method and some arguments, and will receive a >> > > formatted response. All request formats, take a list of >> > > named parameters. The required parameters method and >> > > api_key specify the calling method and the application key >> > > respectively. Optionally, the format parameter is used to >> > > specify the response format. The method arguments and >> > > responses are formatted based on the calling convention. >> > > > >> > > > The problems I see with implementing the Flickr API are: >> > > > The application key: Flickr requires that all applications >> > > using the Flickr API specify an application key. This key >> > > is obtained by going to the Flickr site and registering the >> > > client application for either commercial or non-commercial >> > > usage. This works well for a central service like >> > > Flickr. I believe that it works less well for a product >> > > such as Gallery3 which is not a centralized service. >> > > > Authentication seems to be external to the client. If >> > > the client is a web application, then it is redirected to >> > > Flicker auth api, when then redirects to an application >> > specific >> > > authentication callback. As part of the parameters on the >> > > redirect, there is a unique key which can be converted as to a >> > > authorization token. >> > > > >> > > > What I propose doing is creating a API that is based on >> > > Flickr's approach, but with some signification differences: >> > > > Do away with the application key. In Gallery's >> > > environment it adds no value. >> > > > No login required. Instead, a Gallery3 user would login to >> > the >> > > gallery3 instance and request an authentication token which >> > > would be entered and stored in the client. This >> > > authentication token would be used as a shared secret to sign >> > > the request. >> > > > Request signing would happen just like the Flickr API were >> > all >> > > the parameters are combined with the authentication token and >> > a >> > > md5 hash is calculated and supplied with the request. >> > > > All update requests would be signed, unsigned requests would >> > > be treated as group everybody. >> > > > The URL for the API would be: >> > > > >> > > >> > >> > http://<domain>/gallery3/index.php/<module>/rest/<resource>/<method>?<parms> >> >> > > > To implement other protocols the /rest/ component could be >> > > replaced with json, rpc, or soap, but for the initial >> > > implementation I would suggest only implementing rest or json. >> > > > >> > > > Using the Kohana routing the url would be rewritten such >> > that >> > > the actual controller called would be Rest_Controller. The >> > > controller would be responsible for validating the security, >> > > decoding the request, and calling the appropriate module >> > > supplied api. >> > > > >> > > > This is as far as I got and just wanted to get some early >> > feedback.> > >> > > > Thanks >> > > > Tim >> > > > Website: http://www.timalmdal.com >> > > > >> > > > ------------------------------------------------------------- >> > -- >> > > --------------- >> > > > Let Crystal Reports handle the reporting - Free Crystal >> > > Reports 2008 30-Day >> > > > trial. Simplify your report design, integration and >> > deployment >> > > - and focus on >> > > > what you do best, core application coding. Discover what's >> > new with >> > > > Crystal Reports now. http://p.sf.net/sfu/bobj- >> > > july_______________________________________________> Gallery- >> > > core mailing list >> > > > Gal...@li... >> > > > https://lists.sourceforge.net/lists/listinfo/gallery-core >> > > >> > > >> > >> > Website: http://www.timalmdal.com >> > >> > >> > >> >> Website: http://www.timalmdal.com >> >> >> ------------------------------------------------------------------------ >> >> > ---------------------------------------------------------------------------- > -- >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day >> trial. Simplify your report design, integration and deployment - and focus > on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> >> >> ------------------------------------------------------------------------ >> >> __[ g a l l e r y - d e v e l ]_________________________ >> >> [ list info/archive --> http://gallery.sf.net/lists.php ] >> [ gallery info/FAQ/download --> http://gallery.sf.net ] > > > > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > __[ g a l l e r y - d e v e l ]_________________________ > > [ list info/archive --> http://gallery.sf.net/lists.php ] > [ gallery info/FAQ/download --> http://gallery.sf.net ] > |