|
»
»
API development
|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
 |
API development
by Serguei Dosyukov
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Per
request I am starting a discussion about possible features for API which could
be used to integrate with outside systems. My
initial request was to see if it is possible to support integration with
services like Picnik http://www.picnik.com/info/api
- external hosted photo editor which allows performing some basic editing of
photos containing in the Gallery. Sample
integrations - http://www.picnik.com/info/api/samples Picnik
API - http://www.picnik.com/info/api/reference While
I do like editor in particular, I think generic G3 API would be useful
integrating with other solutions out there I
would start with the following: ·
(Export)
Ability to build secure URL or Form data to expose access to the edited image (original
image or last edited version). As you can find here - http://www.picnik.com/info/api/reference/_import
– PAPI suggests 3 possible solutions which could be discussed/supported. ·
(Import)
ability to download edited version back from provided URL or image data posted
back via provided URL - http://www.picnik.com/info/api/reference/_export ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge __[ 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 ] |
|
|
Re: API development
by Chris Kelly-2
::
Rate this Message:
Serguei Dosyukov wrote:
> Per request I am starting a discussion about possible features for API > which could be used to integrate with outside systems. > > My initial request was to see if it is possible to support integration > with services like Picnik http://www.picnik.com/info/api - external > hosted photo editor which allows performing some basic editing of photos > containing in the Gallery. > > Sample integrations - http://www.picnik.com/info/api/samples > > Picnik API - http://www.picnik.com/info/api/reference > > While I do like editor in particular, I think generic G3 API would be > useful integrating with other solutions out there > > I would start with the following: > > · (Export) Ability to build secure URL or Form data to expose > access to the edited image (original image or last edited version). As > you can find here - http://www.picnik.com/info/api/reference/_import – > PAPI suggests 3 possible solutions which could be discussed/supported. > It would be nice if URL built would not expose actual image, but rather > provide access in the way as it were in G2 since we do not care here > about the speed or simplicity. > > · (Import) ability to download edited version back from provided > URL or image data posted back via provided URL - > http://www.picnik.com/info/api/reference/_export Thanks for starting this discussion Serguei! Gallery 3 does need a way for other applications to communicate with it. A lot of time was spent pursuing a REST approach but it's not functional and will likely be dropped from Gallery 3 before 3.0 ships. I've created a new codex page to keep track of some ideas here, and added my initial thoughts to it here: http://codex.gallery2.org/Gallery3:API Once we have a list of 'Must Haves' and 'Nice To Haves', some people can build reference clients that work with what they want to work with (I'll be putting the finishing touches on a partially complete gallery <-> f-spot tag synchronization tool I started a few years ago for Gallery 2) and then we can build the backend of the API into Gallery 3. For reference, here's the specification for the Gallery Remote protocol used in Gallery 1 and Gallery 2: http://codex.gallery2.org/Gallery_Remote:Protocol -Chris ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge __[ 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 ] |
|
|
|
|
|
Re: API development
by Chris Kelly-2
::
Rate this Message:
It's a wiki page so you can edit it the same as me :) I'd
like to keep it somewhat generic because we don't want implementation specific things to cloud the design process, but having some details does make sense, so I added a section at the bottom. If you're willing to publicly commit to building a Picnik integration, please include your thoughts on that wiki page. Everyone else: if there is an API usage sceneraio that you are interested in that you are willing to publicly commit to working on (iPhone app? Android app? Facebook app? Flickr sync? Lightroom export plugin? iPhoto export plugin? f-spot export plugin? etc) please add your info to that page as well. -Chris Serguei Dosyukov wrote: > Thank you, Chris > > I have visited the page mentioned, it is very generic at this time Do > you think we could incorporate some ideas mentioned so far so people who > are not part of this email list could get a feel of what we are discussing? > > > > Best regards, > > Serguei Dosyukov > > > >> Chris Kelly wrote: > >> > >> Serguei Dosyukov wrote: > >> > Per request I am starting a discussion about possible features for > >> API > >> > which could be used to integrate with outside systems. > >> > > >> > My initial request was to see if it is possible to support > >> integration > >> > with services like Picnik http://www.picnik.com/info/api - external > >> > hosted photo editor which allows performing some basic editing of > >> photos > >> > containing in the Gallery. > >> > > >> > Sample integrations - http://www.picnik.com/info/api/samples > >> > > >> > Picnik API - http://www.picnik.com/info/api/reference > >> > > >> > While I do like editor in particular, I think generic G3 API would > >> > be useful integrating with other solutions out there > >> > > >> > I would start with the following: > >> > > >> > · (Export) Ability to build secure URL or Form data to expose > >> > access to the edited image (original image or last edited version). > >> As > >> > you can find here - http://www.picnik.com/info/api/reference/_import > >> -- > >> > PAPI suggests 3 possible solutions which could be > >> discussed/supported. > >> > It would be nice if URL built would not expose actual image, but > >> rather > >> > provide access in the way as it were in G2 since we do not care here > >> > about the speed or simplicity. > >> > > >> > · (Import) ability to download edited version back from > >> provided > >> > URL or image data posted back via provided URL - > >> > http://www.picnik.com/info/api/reference/_export > >> > >> Thanks for starting this discussion Serguei! > >> > >> Gallery 3 does need a way for other applications to communicate with > >> it. A lot of time was spent pursuing a REST approach but it's not > >> functional and will likely be dropped from Gallery 3 before 3.0 ships. > >> > >> I've created a new codex page to keep track of some ideas here, and > >> added my initial thoughts to it here: > >> > >> http://codex.gallery2.org/Gallery3:API > >> > >> Once we have a list of 'Must Haves' and 'Nice To Haves', some people > >> can build reference clients that work with what they want to work with > >> (I'll be putting the finishing touches on a partially complete gallery > >> <-> f-spot tag synchronization tool I started a few years ago for > >> Gallery > >> 2) and then we can build the backend of the API into Gallery 3. > >> > >> For reference, here's the specification for the Gallery Remote > >> protocol used in Gallery 1 and Gallery 2: > >> > >> http://codex.gallery2.org/Gallery_Remote:Protocol > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > > > ------------------------------------------------------------------------ > > __[ 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 ] ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge __[ 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 ] |
|
|
Re: API development
by Gaynor McCartney
::
Rate this Message:
Hi Chris,
I don;t know wnough to write anything like that, but am just wondering if the API you are discussing is the G3 version to use for Google Maps. When my head gets back to usable concentration stage I hope to work on Google Maps module (or whatever modules are is now called) Regards, Gaynor ----- Original Message ----- From: "Chris Kelly" <ckdake@...> To: <gallery-devel@...> Cc: "Serguei Dosyukov" <webmaster@...> Sent: Tuesday, July 21, 2009 1:04 PM Subject: Re: [Gallery-devel] API development > It's a wiki page so you can edit it the same as me :) I'd > like to keep it somewhat generic because we don't want > implementation specific things to cloud the design process, > but having some details does make sense, so I added a > section at the bottom. > > If you're willing to publicly commit to building a Picnik > integration, please include your thoughts on that wiki page. > > Everyone else: if there is an API usage sceneraio that you > are interested in that you are willing to publicly commit to > working on (iPhone app? Android app? Facebook app? Flickr > sync? Lightroom export plugin? iPhoto export plugin? f-spot > export plugin? etc) please add your info to that page as well. > > -Chris > > Serguei Dosyukov wrote: >> Thank you, Chris >> >> I have visited the page mentioned, it is very generic at this time Do >> you think we could incorporate some ideas mentioned so far so people who >> are not part of this email list could get a feel of what we are >> discussing? >> >> >> >> Best regards, >> >> Serguei Dosyukov >> >> >> >>> Chris Kelly wrote: >> >>> >> >>> Serguei Dosyukov wrote: >> >>> > Per request I am starting a discussion about possible features for >> >>> API >> >>> > which could be used to integrate with outside systems. >> >>> > >> >>> > My initial request was to see if it is possible to support >> >>> integration >> >>> > with services like Picnik http://www.picnik.com/info/api - external >> >>> > hosted photo editor which allows performing some basic editing of >> >>> photos >> >>> > containing in the Gallery. >> >>> > >> >>> > Sample integrations - http://www.picnik.com/info/api/samples >> >>> > >> >>> > Picnik API - http://www.picnik.com/info/api/reference >> >>> > >> >>> > While I do like editor in particular, I think generic G3 API would >> >>> > be useful integrating with other solutions out there >> >>> > >> >>> > I would start with the following: >> >>> > >> >>> > · (Export) Ability to build secure URL or Form data to expose >> >>> > access to the edited image (original image or last edited version). >> >>> As >> >>> > you can find here - http://www.picnik.com/info/api/reference/_import >> >>> -- >> >>> > PAPI suggests 3 possible solutions which could be >> >>> discussed/supported. >> >>> > It would be nice if URL built would not expose actual image, but >> >>> rather >> >>> > provide access in the way as it were in G2 since we do not care here >> >>> > about the speed or simplicity. >> >>> > >> >>> > · (Import) ability to download edited version back from >> >>> provided >> >>> > URL or image data posted back via provided URL - >> >>> > http://www.picnik.com/info/api/reference/_export >> >>> >> >>> Thanks for starting this discussion Serguei! >> >>> >> >>> Gallery 3 does need a way for other applications to communicate with >> >>> it. A lot of time was spent pursuing a REST approach but it's not >> >>> functional and will likely be dropped from Gallery 3 before 3.0 ships. >> >>> >> >>> I've created a new codex page to keep track of some ideas here, and >> >>> added my initial thoughts to it here: >> >>> >> >>> http://codex.gallery2.org/Gallery3:API >> >>> >> >>> Once we have a list of 'Must Haves' and 'Nice To Haves', some people >> >>> can build reference clients that work with what they want to work with >> >>> (I'll be putting the finishing touches on a partially complete gallery >> >>> <-> f-spot tag synchronization tool I started a few years ago for >> >>> Gallery >> >>> 2) and then we can build the backend of the API into Gallery 3. >> >>> >> >>> For reference, here's the specification for the Gallery Remote >> >>> protocol used in Gallery 1 and Gallery 2: >> >>> >> >>> http://codex.gallery2.org/Gallery_Remote:Protocol >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> Enter the BlackBerry Developer Challenge >> This is your chance to win up to $100,000 in prizes! For a limited time, >> vendors submitting new applications to BlackBerry App World(TM) will have >> the opportunity to enter the BlackBerry Developer Challenge. See full >> prize >> details at: http://p.sf.net/sfu/Challenge >> >> >> ------------------------------------------------------------------------ >> >> __[ 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 ] > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full > prize > details at: http://p.sf.net/sfu/Challenge > __[ 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 ] ------------------------------------------------------------------------------ __[ 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 ] |
|
|
Re: API development
by Chris Kelly-2
::
Rate this Message:
This API will be for other applications and website to
communicate with Gallery 3. If you wanted to build a tool that runs on a site, pulls info from a Gallery 3 somewhere else, and displays it on a Google map, this API is for you! If you're trying to wrap your head around embedding Google Maps inside of a G3, this is not the API you are looking for. -Chris Gaynor McCartney wrote: > Hi Chris, > I don;t know wnough to write anything like that, but am just wondering > if the API you are discussing is the G3 version to use for Google Maps. > > When my head gets back to usable concentration stage I hope to work on > Google Maps module (or whatever modules are is now called) > > Regards, > Gaynor > > > > ----- Original Message ----- From: "Chris Kelly" <ckdake@...> > To: <gallery-devel@...> > Cc: "Serguei Dosyukov" <webmaster@...> > Sent: Tuesday, July 21, 2009 1:04 PM > Subject: Re: [Gallery-devel] API development > > >> It's a wiki page so you can edit it the same as me :) I'd >> like to keep it somewhat generic because we don't want >> implementation specific things to cloud the design process, >> but having some details does make sense, so I added a >> section at the bottom. >> >> If you're willing to publicly commit to building a Picnik >> integration, please include your thoughts on that wiki page. >> >> Everyone else: if there is an API usage sceneraio that you >> are interested in that you are willing to publicly commit to >> working on (iPhone app? Android app? Facebook app? Flickr >> sync? Lightroom export plugin? iPhoto export plugin? f-spot >> export plugin? etc) please add your info to that page as well. >> >> -Chris >> >> Serguei Dosyukov wrote: >>> Thank you, Chris >>> >>> I have visited the page mentioned, it is very generic at this time Do >>> you think we could incorporate some ideas mentioned so far so people who >>> are not part of this email list could get a feel of what we are >>> discussing? >>> >>> >>> >>> Best regards, >>> >>> Serguei Dosyukov >>> >>> >>> >>>> Chris Kelly wrote: >>> >>>> >>> >>>> Serguei Dosyukov wrote: >>> >>>> > Per request I am starting a discussion about possible features for >>> >>>> API >>> >>>> > which could be used to integrate with outside systems. >>> >>>> > >>> >>>> > My initial request was to see if it is possible to support >>> >>>> integration >>> >>>> > with services like Picnik http://www.picnik.com/info/api - external >>> >>>> > hosted photo editor which allows performing some basic editing of >>> >>>> photos >>> >>>> > containing in the Gallery. >>> >>>> > >>> >>>> > Sample integrations - http://www.picnik.com/info/api/samples >>> >>>> > >>> >>>> > Picnik API - http://www.picnik.com/info/api/reference >>> >>>> > >>> >>>> > While I do like editor in particular, I think generic G3 API would >>> >>>> > be useful integrating with other solutions out there >>> >>>> > >>> >>>> > I would start with the following: >>> >>>> > >>> >>>> > · (Export) Ability to build secure URL or Form data to expose >>> >>>> > access to the edited image (original image or last edited version). >>> >>>> As >>> >>>> > you can find here - http://www.picnik.com/info/api/reference/_import >>> >>>> -- >>> >>>> > PAPI suggests 3 possible solutions which could be >>> >>>> discussed/supported. >>> >>>> > It would be nice if URL built would not expose actual image, but >>> >>>> rather >>> >>>> > provide access in the way as it were in G2 since we do not care here >>> >>>> > about the speed or simplicity. >>> >>>> > >>> >>>> > · (Import) ability to download edited version back from >>> >>>> provided >>> >>>> > URL or image data posted back via provided URL - >>> >>>> > http://www.picnik.com/info/api/reference/_export >>> >>>> >>> >>>> Thanks for starting this discussion Serguei! >>> >>>> >>> >>>> Gallery 3 does need a way for other applications to communicate with >>> >>>> it. A lot of time was spent pursuing a REST approach but it's not >>> >>>> functional and will likely be dropped from Gallery 3 before 3.0 ships. >>> >>>> >>> >>>> I've created a new codex page to keep track of some ideas here, and >>> >>>> added my initial thoughts to it here: >>> >>>> >>> >>>> http://codex.gallery2.org/Gallery3:API >>> >>>> >>> >>>> Once we have a list of 'Must Haves' and 'Nice To Haves', some people >>> >>>> can build reference clients that work with what they want to work with >>> >>>> (I'll be putting the finishing touches on a partially complete gallery >>> >>>> <-> f-spot tag synchronization tool I started a few years ago for >>> >>>> Gallery >>> >>>> 2) and then we can build the backend of the API into Gallery 3. >>> >>>> >>> >>>> For reference, here's the specification for the Gallery Remote >>> >>>> protocol used in Gallery 1 and Gallery 2: >>> >>>> >>> >>>> http://codex.gallery2.org/Gallery_Remote:Protocol ------------------------------------------------------------------------------ __[ 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 ] |
|
|
Re: API development
by Gaynor McCartney
::
Rate this Message:
Thanks Chris.
This does seeem an important difference. I hope it will be mentioned in the documentation. I'm filing this for myself too. I can see a possibility of doing both thse. My main interest is "embedding Google Maps inside of a G3" but as I have galleries on various websites it will be helpful for maps in any site to be able to access photos on the different sites Gaynor ----- Original Message ----- From: "Chris Kelly" <ckdake@...> To: <gallery-devel@...> Cc: "Gaynor McCartney" <gaynormcc@...> Sent: Wednesday, July 22, 2009 4:24 AM Subject: Re: [Gallery-devel] API development > This API will be for other applications and website to > communicate with Gallery 3. If you wanted to build a tool > that runs on a site, pulls info from a Gallery 3 somewhere > else, and displays it on a Google map, this API is for you! > > If you're trying to wrap your head around embedding Google > Maps inside of a G3, this is not the API you are looking for. > > -Chris > > Gaynor McCartney wrote: >> Hi Chris, >> I don;t know wnough to write anything like that, but am just wondering >> if the API you are discussing is the G3 version to use for Google Maps. >> >> When my head gets back to usable concentration stage I hope to work on >> Google Maps module (or whatever modules are is now called) >> >> Regards, >> Gaynor >> >> >> >> ----- Original Message ----- From: "Chris Kelly" <ckdake@...> >> To: <gallery-devel@...> >> Cc: "Serguei Dosyukov" <webmaster@...> >> Sent: Tuesday, July 21, 2009 1:04 PM >> Subject: Re: [Gallery-devel] API development >> >> >>> It's a wiki page so you can edit it the same as me :) I'd >>> like to keep it somewhat generic because we don't want >>> implementation specific things to cloud the design process, >>> but having some details does make sense, so I added a >>> section at the bottom. >>> >>> If you're willing to publicly commit to building a Picnik >>> integration, please include your thoughts on that wiki page. >>> >>> Everyone else: if there is an API usage sceneraio that you >>> are interested in that you are willing to publicly commit to >>> working on (iPhone app? Android app? Facebook app? Flickr >>> sync? Lightroom export plugin? iPhoto export plugin? f-spot >>> export plugin? etc) please add your info to that page as well. >>> >>> -Chris >>> >>> Serguei Dosyukov wrote: >>>> Thank you, Chris >>>> >>>> I have visited the page mentioned, it is very generic at this time Do >>>> you think we could incorporate some ideas mentioned so far so people >>>> who >>>> are not part of this email list could get a feel of what we are >>>> discussing? >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Serguei Dosyukov >>>> >>>> >>>> >>>>> Chris Kelly wrote: >>>> >>>>> >>>> >>>>> Serguei Dosyukov wrote: >>>> >>>>> > Per request I am starting a discussion about possible features for >>>> >>>>> API >>>> >>>>> > which could be used to integrate with outside systems. >>>> >>>>> > >>>> >>>>> > My initial request was to see if it is possible to support >>>> >>>>> integration >>>> >>>>> > with services like Picnik http://www.picnik.com/info/api - external >>>> >>>>> > hosted photo editor which allows performing some basic editing of >>>> >>>>> photos >>>> >>>>> > containing in the Gallery. >>>> >>>>> > >>>> >>>>> > Sample integrations - http://www.picnik.com/info/api/samples >>>> >>>>> > >>>> >>>>> > Picnik API - http://www.picnik.com/info/api/reference >>>> >>>>> > >>>> >>>>> > While I do like editor in particular, I think generic G3 API would >>>> >>>>> > be useful integrating with other solutions out there >>>> >>>>> > >>>> >>>>> > I would start with the following: >>>> >>>>> > >>>> >>>>> > · (Export) Ability to build secure URL or Form data to >>>>> > expose >>>> >>>>> > access to the edited image (original image or last edited version). >>>> >>>>> As >>>> >>>>> > you can find here - http://www.picnik.com/info/api/reference/_import >>>> >>>>> -- >>>> >>>>> > PAPI suggests 3 possible solutions which could be >>>> >>>>> discussed/supported. >>>> >>>>> > It would be nice if URL built would not expose actual image, but >>>> >>>>> rather >>>> >>>>> > provide access in the way as it were in G2 since we do not care here >>>> >>>>> > about the speed or simplicity. >>>> >>>>> > >>>> >>>>> > · (Import) ability to download edited version back from >>>> >>>>> provided >>>> >>>>> > URL or image data posted back via provided URL - >>>> >>>>> > http://www.picnik.com/info/api/reference/_export >>>> >>>>> >>>> >>>>> Thanks for starting this discussion Serguei! >>>> >>>>> >>>> >>>>> Gallery 3 does need a way for other applications to communicate with >>>> >>>>> it. A lot of time was spent pursuing a REST approach but it's not >>>> >>>>> functional and will likely be dropped from Gallery 3 before 3.0 ships. >>>> >>>>> >>>> >>>>> I've created a new codex page to keep track of some ideas here, and >>>> >>>>> added my initial thoughts to it here: >>>> >>>>> >>>> >>>>> http://codex.gallery2.org/Gallery3:API >>>> >>>>> >>>> >>>>> Once we have a list of 'Must Haves' and 'Nice To Haves', some people >>>> >>>>> can build reference clients that work with what they want to work with >>>> >>>>> (I'll be putting the finishing touches on a partially complete gallery >>>> >>>>> <-> f-spot tag synchronization tool I started a few years ago for >>>> >>>>> Gallery >>>> >>>>> 2) and then we can build the backend of the API into Gallery 3. >>>> >>>>> >>>> >>>>> For reference, here's the specification for the Gallery Remote >>>> >>>>> protocol used in Gallery 1 and Gallery 2: >>>> >>>>> >>>> >>>>> http://codex.gallery2.org/Gallery_Remote:Protocol > > > ------------------------------------------------------------------------------ > __[ 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 ] ------------------------------------------------------------------------------ __[ 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 ] |
|
|
Re: API development
by Tim Almdal
::
Rate this Message:
There is in case people have forgotten, a Google maps module (gmap) in gallery3-contrib
http://github.com/gallery/gallery3-contrib/tree/master ----- Original Message ----- From: Gaynor McCartney <gaynormcc@...> Date: Wednesday, July 22, 2009 3:06 am Subject: Re: [Gallery-devel] API development To: Chris Kelly <ckdake@...>, gallery-devel@... > Thanks Chris. > This does seeem an important difference. I hope it will be > mentioned in the > documentation. > I'm filing this for myself too. > > I can see a possibility of doing both thse. > My main interest is "embedding Google Maps inside of a G3" > but as I have > galleries on various websites > it will be helpful for maps in any site to be able to access > photos on the > different sites > > Gaynor > > ----- Original Message ----- > From: "Chris Kelly" <ckdake@...> > To: <gallery-devel@...> > Cc: "Gaynor McCartney" <gaynormcc@...> > Sent: Wednesday, July 22, 2009 4:24 AM > Subject: Re: [Gallery-devel] API development > > > > This API will be for other applications and website to > > communicate with Gallery 3. If you wanted to build a tool > > that runs on a site, pulls info from a Gallery 3 somewhere > > else, and displays it on a Google map, this API is for you! > > > > If you're trying to wrap your head around embedding Google > > Maps inside of a G3, this is not the API you are looking for. > > > > -Chris > > > > Gaynor McCartney wrote: > >> Hi Chris, > >> I don;t know wnough to write anything like that, but am just > wondering>> if the API you are discussing is the G3 version to > use for Google Maps. > >> > >> When my head gets back to usable concentration stage I hope > to work on > >> Google Maps module (or whatever modules are is now called) > >> > >> Regards, > >> Gaynor > >> > >> > >> > >> ----- Original Message ----- From: "Chris Kelly" > <ckdake@...>>> To: <gallery-devel@...> > >> Cc: "Serguei Dosyukov" <webmaster@...> > >> Sent: Tuesday, July 21, 2009 1:04 PM > >> Subject: Re: [Gallery-devel] API development > >> > >> > >>> It's a wiki page so you can edit it the same as me :) I'd > >>> like to keep it somewhat generic because we don't want > >>> implementation specific things to cloud the design process, > >>> but having some details does make sense, so I added a > >>> section at the bottom. > >>> > >>> If you're willing to publicly commit to building a Picnik > >>> integration, please include your thoughts on that wiki page. > >>> > >>> Everyone else: if there is an API usage sceneraio that you > >>> are interested in that you are willing to publicly commit to > >>> working on (iPhone app? Android app? Facebook app? Flickr > >>> sync? Lightroom export plugin? iPhoto export plugin? f-spot > >>> export plugin? etc) please add your info to that page as well. > >>> > >>> -Chris > >>> > >>> Serguei Dosyukov wrote: > >>>> Thank you, Chris > >>>> > >>>> I have visited the page mentioned, it is very generic at > this time Do > >>>> you think we could incorporate some ideas mentioned so far > so people > >>>> who > >>>> are not part of this email list could get a feel of what we are > >>>> discussing? > >>>> > >>>> > >>>> > >>>> Best regards, > >>>> > >>>> Serguei Dosyukov > >>>> > >>>> > >>>> > >>>>> Chris Kelly wrote: > >>>> > >>>>> > >>>> > >>>>> Serguei Dosyukov wrote: > >>>> > >>>>> > Per request I am starting a discussion about possible > features for > >>>> > >>>>> API > >>>> > >>>>> > which could be used to integrate with outside systems. > >>>> > >>>>> > > >>>> > >>>>> > My initial request was to see if it is possible to support > >>>> > >>>>> integration > >>>> > >>>>> > with services like Picnik http://www.picnik.com/info/api > - external > >>>> > >>>>> > hosted photo editor which allows performing some basic > editing of > >>>> > >>>>> photos > >>>> > >>>>> > containing in the Gallery. > >>>> > >>>>> > > >>>> > >>>>> > Sample integrations - http://www.picnik.com/info/api/samples > >>>> > >>>>> > > >>>> > >>>>> > Picnik API - http://www.picnik.com/info/api/reference > >>>> > >>>>> > > >>>> > >>>>> > While I do like editor in particular, I think generic G3 > API would > >>>> > >>>>> > be useful integrating with other solutions out there > >>>> > >>>>> > > >>>> > >>>>> > I would start with the following: > >>>> > >>>>> > > >>>> > >>>>> > · > (Export) Ability to build secure URL or Form data to > >>>>> > expose > >>>> > >>>>> > access to the edited image (original image or last > edited version). > >>>> > >>>>> As > >>>> > >>>>> > you can find here - > http://www.picnik.com/info/api/reference/_import>>>> > >>>>> -- > >>>> > >>>>> > PAPI suggests 3 possible solutions which could be > >>>> > >>>>> discussed/supported. > >>>> > >>>>> > It would be nice if URL built would not expose actual > image, but > >>>> > >>>>> rather > >>>> > >>>>> > provide access in the way as it were in G2 since we do > not care here > >>>> > >>>>> > about the speed or simplicity. > >>>> > >>>>> > > >>>> > >>>>> > · > (Import) ability to download edited version back from > >>>> > >>>>> provided > >>>> > >>>>> > URL or image data posted back via provided URL - > >>>> > >>>>> > http://www.picnik.com/info/api/reference/_export > >>>> > >>>>> > >>>> > >>>>> Thanks for starting this discussion Serguei! > >>>> > >>>>> > >>>> > >>>>> Gallery 3 does need a way for other applications to > communicate with > >>>> > >>>>> it. A lot of time was spent pursuing a REST approach but > it's not > >>>> > >>>>> functional and will likely be dropped from Gallery 3 > before 3.0 ships. > >>>> > >>>>> > >>>> > >>>>> I've created a new codex page to keep track of some ideas > here, and > >>>> > >>>>> added my initial thoughts to it here: > >>>> > >>>>> > >>>> > >>>>> http://codex.gallery2.org/Gallery3:API > >>>> > >>>>> > >>>> > >>>>> Once we have a list of 'Must Haves' and 'Nice To Haves', > some people > >>>> > >>>>> can build reference clients that work with what they want > to work with > >>>> > >>>>> (I'll be putting the finishing touches on a partially > complete gallery > >>>> > >>>>> <-> f-spot tag synchronization tool I started a few > years ago for > >>>> > >>>>> Gallery > >>>> > >>>>> 2) and then we can build the backend of the API into > Gallery 3. > >>>> > >>>>> > >>>> > >>>>> For reference, here's the specification for the Gallery Remote > >>>> > >>>>> protocol used in Gallery 1 and Gallery 2: > >>>> > >>>>> > >>>> > >>>>> http://codex.gallery2.org/Gallery_Remote:Protocol > > > > > > --------------------------------------------------------------- > --------------- > > __[ 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 ] > > > ----------------------------------------------------------------- > ------------- > __[ 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 ] Website: http://www.timalmdal.com ------------------------------------------------------------------------------ __[ 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 ] |
|
|
Re: API development
by Kirk Steffensen
::
Rate this Message:
Chris, et al,
I'm finally getting back to coding after a year off for real life. (Life has finally settled out enough for me to have some fun coding again...) I'm very interested in working on the embedding API. A lot of the work I've done on G2Image v3.1 has been to make it easier to reach into G2 and pull out a useful array of all of the info about a G2 item to make it easier to sort, etc, external to G2, since the G2 embedding API was fairly limited in it's ability to ask for much beyond the image block. I'd love to move a lot of that thought process into an embedding API (even if the specific methods that I developed for G2 are no longer valid.) I'm woefully behind on this list, I'll try to catch up over the next week or so. In the meantime, could you give me a 30-second synopsis of the status of embedding API development? Is anyone actively working on it that I should coordinate with? Is there a part of the G3 code that it would make sense to look at first? Tim Almdal pointed me to a Wordpress plugin for Kohana here: http://dev.kohanaphp.com/projects/wordpress Are there any other parts of the code that I should get to know in order to start working on embedding? Thanks! Kirk Kirk Steffensen G2Image developer (hopefully soon to be G3Image developer...) http://g2image.steffensenfamily.com P.S. Sorry for the mail list spam while I was on vacation. I forgot to check the box in gmail that says "Only send to persons in My Contacts". Doh... 2009/7/20 Chris Kelly <ckdake@...> It's a wiki page so you can edit it the same as me :) I'd ------------------------------------------------------------------------------ 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 ] |
|
|
Re: API development
by Chris Kelly-2
::
Rate this Message:
Great to hear you have some time for Gallery again!
The API discussion here is more for other apps to talk to Gallery, and not necessarily for doing embedding. I'm not aware of any effort to embed G3 in something like Wordpress yes, but I would love to be able to switch a few Drupal+G2s that I have to Drupal+G3. The G3 codebase is a lot easier to get into than G2, so you should be able to start digging around pretty easily and ask specific questions as you have them, -Chris On Aug 7, 2009, at 9:42 PM, Kirk Steffensen wrote: Chris, et al, ------------------------------------------------------------------------------ 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 ] |
| Free embeddable forum powered by Nabble | Forum Help |
