From: Patrice F. <fr...@fr...> - 2005-01-16 08:19:01
|
i would be also interested in defining or using such protocol. i'm the imgsvr author. Regards Patrice=20 Le Mercredi 12 Janvier 2005 17:10, Chris Kelly a =E9crit : > -- Bharat Mediratta <bh...@me...> wrote: > > ms...@fr... wrote: > > > Hi, > > > > > > I'm writing a script to share my Gallery with > > > > iPhoto using Richard > > > > > Clamp's Perl DPAP library > > (http://cgi.sfu.ca/~jdbates/moin/moin.cgi/Gallery&DPAP) > > > There's a > > > > > working prototype, & any help would be very much > > > > appreciated! > > > > > Right now my big question is - before adding > > > > features - how best to > > > > > interface with Gallery. I would really appreciate > > > > input from Gallery > > > > > developers > > (http://cgi.sfu.ca/~jdbates/moin/moin.cgi/Gallery&DPAP) > > > Nice document. I agree that trying to rewrite the > > G2 persistence layer > > in Perl is probably going to cause trouble. And at > > the other end of the > > spectrum, scraping the web pages will be a > > nightmare. > > > > We've had this discussion before, and I think that > > we've always come > > back to the thought of using an XMLRPC or SOAP > > interface. Now that the > > GalleryCoreAPI has reached a reasonable level of > > maturity, it should not > > be all that difficult to start writing an XMLRPC (or > > SOAP, or both) > > module that exports certain parts of the API. > > > > The long term plan is that we will create a new > > XMLRPC or SOAP API and > > start by supporting all the functionality that > > Gallery Remote needs. We > > (the team, not me personally) started writing a > > description of what that > > protocol would look like: > > http://gallery.sf.net/docs.php?page=3Dgallery-remote.protocol3.php > > > The easiest approach would be just to expose all of > > the GalleryCoreAPI > > methods as a web service. However, that will lead > > us to trouble on > > several fronts: > > > > 1. Security - some of these API methods are designed > > to be used by > > helper methods which expect that you have privileges > > to look at > > whatever data that you want. > > > > 2. Locking - these API methods expect that you have > > locked the > > appropriate elements, and locks only persist for a > > single request so > > need to do several operations at once (lock, change, > > unlock). > > > > 3. Performance - we look up data from the database > > and cache it in the > > request, so the more similar operations that we do > > in a single request, > > the better our performance will be. > > > > So it seems like we should start creating a task > > driven API for the > > basic operations that we want to make available. > > The minimum set of > > tasks is defined by whatever Gallery Remote needs, > > but obviously we can > > create more tasks (where a task is defined as a > > single API method) as > > necessary. > > > > In our new module, we have to make sure that we > > handle all the > > complexity of locking, permission checking, etc for > > each task. > > > > We also need to think about what kinds of data > > structures that we'll > > need in order to efficiently pass data back and > > forth. > > > > I know that in the past people have been very > > excited about working on > > this. I dampened some of the enthusiasm a year ago > > because I felt that > > it was more important to focus our dev resources on > > core tasks. But in > > retrospect, I think that this was the wrong approach > > because some of > > those resources that were excited to work on > > XMLRPC/SOAP were not as > > excited (read: not as productive) working on other > > tasks instead. > > > > So .. I throw it open to any takers. If you're > > interested in working on > > this module let's talk! > > After talking to Bharat as well as some people in my > CS Senior Design Class, It looks like a team of us are > going to take up the task of writing a remote protocol > for G2. > > The proposed full scope of our project is: > > -some sort of remote protocol, probably using XMLRPC > or SOAP but we'll do some in depth research first to > see if there are any other options and which one is > the way to go. > > -mDNS responder module for dynamic service discovery > of Gallery installs on a broadcast reachable subnet > (most likely using > http://developer.apple.com/darwin/projects/rendezvous/) > > -Client application for > PocketPC/WindowsCE/WindowsMobile for browsing and > adding items to a Gallery, automatically finding > Gallery installs on the lan. > > -possible WindowsXP publishing wizard, iPhoto plugin, > and maybe something native to Linux, all of which > would use the new protocol. > > There should be a website and formal plan for this > sometime next week, and I'll pass that information > along to the list. > > -Chris > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > __[ 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 ] --=20 ---- gpg --keyserver pgp.mit.edu --recv-key 139A6156 http://imgsvr.org |