I was a bit surprised to see smugmug not represented.

The main thing I'd like reviewed before this is committed is how it uses the cache. Unlike flickr for example, the smugmug api only uses the API to request a SessionID. For all other method calls only the SessionID is needed. A SessionID times out after about 6 Hours. So if the call to retrieve a SessionID is being cached, then it might later be invalid if pulled from the cache.

I could just set $cached=false in the method call to get the SessionID, however that would result in nothing being cached since an arghash is used for caching by emfield_request_xml function in emfield.module file.

Possible solutions to this caching issue:

1. Add another argument to emfield_request_xml with a list of args to exclude from the arghash. That would allow me to call for a new SessionID from smugmug (NO caching), and then tell emfield_request_xml NOT to include SessionID in arghash for all other methods.

2. Provide some way to set the duration of the cache when calling emfield_request_xml. This would be best as I could just set that particular cache item to time out after some period (5 hrs to be safe).

Is 2 even possible?

Anyway, functionality definitely works for me, just concerned about poor use of caching causing overload on provider.

CommentFileSizeAuthor
#3 smugmug.inc_.zip4.17 KBwinston
smugmug.inc_.zip3.68 KBwinston
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

winston’s picture

Assigned: winston » Unassigned
winston’s picture

Status: Needs review » Needs work

OK, so upon further experimentation and research I'm finding that I can't tell for sure when the smugmug sessionid (required for all subsequent api calls) times out. It is not officially documented. The smugmug forum (dgrin) suggests 6 hours, but I just did a test today using an old session id (23.5 hours) and it worked (created a new item so definitely not pulling from page cache or something like that).

Anyway, I have a good idea to deal with forcing the sessionid out of the cache, but it seems silly to just guess what that "forced expiration" time should be so putting this back to "needs work" while I follow up with the smugmug folks to get a definitive answer.

Current the functionality of the patch should work if someone wants to try it for that purpose. The only thing is right now is it isn't caching anything so although it will work, it will be much less efficient so not recommended for production yet.

Hopefully I'll be able to put this back to needs review soon.

winston’s picture

Status: Needs work » Needs review
FileSize
4.17 KB

Fixed the caching issues so set this to needs review. I have a couple of planned enhancements, but this is a functional provider ready to go as far as my testing goes.

Also, it has been run through coder module and passed.

Alex UA’s picture

Wow, that's a really nice service! I'll check with Aaron, since we're really not adding more providers (we're trying to strip them out and make them into their own modules, such as the Media Viddler module), but considering how few photo providers we have (and how few of them seem to work atm) I'm inclined to include this for now.

Also- this is a very well done provider file- thanks for your work!!!

winston’s picture

Hey Alex,

Actually I noticed last night the new media_viddler provider and also your new strategy of splitting out new providers into separate modules. I actually think that is a great idea and am happy to proceed on that basis.

In fact last night I applied for a CVS account referencing this thread.

If it is OK with you then as soon as I get my CVS account I'll go ahead and create the new provider module.

Also, since smugmug also supports high quality video as soon as the image provider is release I'll also create a video provider!

- Peter

winston’s picture

Status: Needs review » Closed (won't fix)

As per new strategy of creating separate module for specific provider I've created a Media: Smugmug module.

This provider will shortly be posted and released there.