Active
Project:
Picasa
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
3 Jan 2009 at 03:52 UTC
Updated:
23 Oct 2009 at 19:54 UTC
Seems there was a duplicated module created after this module, called Google Picasa. It is not in our best interest as a Drupal community to create duplicated modules, and I have filed an issue with the other module in http://drupal.org/node/353738 explaining the reasoning why he should help contribute to this project instead of creating his own "fork". Maybe you could take a look at it and see if there are any valuable differences that could be merged back into this module.
Comments
Comment #1
cyberswat commentedave been looking for quality help with this module for a long time
Comment #2
develcuy commentedI'm not in the D6 way right now, but what about a merge for a later version?
Comment #3
cyberswat commentedI've evaluated the feedback that I've received so far on the d6 port of this module and it seems to be pretty positive. This implementation is a solid approach at creating proper nodes for albums and photos and I believe this framework is the best option for moving forward.
@develCuy would you be interested in helping progress this module?
Comment #4
develcuy commentedI have a different point of view about how to store the data, don't like to use nodes, because I'm in favor of a very lightweight and curl based implementation.
But I don't want to duplicate efforts so...
As I have seen in other modules, perhaps we can split and reuse. I can maintain a "curl engine" and a "cache based storage". So, perhaps you could maintain the "fsockopen engine" and the "node based storage". I can also work in app_key authentication, you in the oauth one, etc...
I do want to join efforts and merge my implementation(it is not a fork) with yours, but also I want to make it plugable, in order to let people adjust the functionalities to their needs.
Blessings!
Comment #5
cyberswat commentedCould you expand a little more on the use cases you are attempting to meet with your module? I'm not entirely sure that I understand what your goals are but do have a few concerns ... for example, cURL has been known to cause issues with widely distributed modules http://drupal.org/search/apachesolr_search/curl_init ... a viable alternative is http://api.drupal.org/api/function/drupal_http_request ... I'm also a little confused about your decision to not use nodes.
Comment #6
develcuy commentedUnless cURL really rocks, it is not that install friendly. So I have decided to move out of cURL for a long while.
About authentication of Drupal as an application with and App Key instead of OAuth or OpenID, I still want it.
And about nodes, OK, no problem, I can live with nodes by now.
So...
It seem like the next step is to put the App Key stuff into your implementation. Do you agree? If so, do you prefer a plugin-in or a patch? (plug-in may require patch also).
Blessings!
Comment #7
cyberswat commented@develCuy As far as I know the Google API's do not support OpenID ... The module that I'm using for authentication with Google is http://drupal.org/project/google_auth ... I think the best approach may be to first provide the api functionality to perform the type of authentication you are looking for through that module and then modify the Picasa module to tie into the changes via the api.
As far as cURL is concerned ... we can accomplish the same functionality by passing various headers through drupal_http_request() ... There's a lot of code in the Picasa module that is doing some neat stuff with an assortment of headers if you'd like to see some examples.
Comment #8
jvieille commentedAny update about this projected effort?
Comment #9
develcuy commentedI have a lot of interest and would be awesome to have sponsorship, but in the meantime I'm waiting for a related paid project, so I can assign time to collaborate with this project.