[Rets-dev] simply picture questions

[Matt Lavallee]

Colby, Scott, et al.,

Here's how MLSNI works...

Every listing has multiple, photo-related fields:
 * PHOTOCOUNT - number of available photos
 * PHOTOMASK  - the list of ordinals for the photos,e.g., "1,2,4,5,6"
 * PHOTODATE - timestamp of the most recent photo update
 * PHOTOCAPTION - (new) caption
 * PHO - photo code (used internally for approvals)
 * C57 - photos aspect ratio is 5x7
 * C810 - photos aspect ratio is 8x10
 * c35 - photos aspect ratio is 3x5
 * RECMODDATE - timestamp of the last listing update

Notably, there is no provision for 4x6 or other aspect ratios, so we ignore
those flags.

It is a bit goofy, but works around most of the shortcomings of RETS 1.5.  Using
the list of ordinals, you could detect when a photo is deleted and a new one
added.  PHOTODATE gets updated whenever there is a photo added, and the
RECMODDATE gets updated whenever a photo is modified or deleted (or any part of
the listing, for that matter, but we always want any listing changes).

So my logic works like this:
- If RECMODDATE is newer than mine and PHOTODATE is the same as mine, compare
their mask to my mask, download where different.  *This is currently a little
broken and takes a workaround.
- If RECMODDATE is the same as mine and PHOTODATE is newer than mine, replace
all photos for the listing that are older than RECMODDATE.

The PHOTOMASK bit handles all but replacements, for which I need the second
condition because I have no way of detecting (nor they of reporting) the change.
Colby's solution would fix this, as would replacing the PHOTOMASK with a list of
MD5 hashes.

RETS2 treats each bit of media as a distinct element, so they have properties
and can (easily) be addressed individually.

-Matt


On Thursday, July 12, 2007 at 12:49 PM, Colby wrote:

> Scott,
> 
> Interesting timing on this question. I was just pondering this same
> question this morning. I'm not sure I have the best answer, but I'll let
> you know my thoughts and what I heard others were doing. If other
> implementors could chime in that would really help too.
> 
> Some RETS implementations support a field on the listing like
> PhotosUpdatedDate that signals that some or all of the photos for a
> particular listing may have updated. That one field represents multiple
> photo objects so you'd need to download all the images for that listing
> to make sure you get the changes. This is better than having to download
> every image for all listings to get photo updates, but you'll still be
> downloading some info that you've previously fetched.
> 
> Taking this a step further...
> 
> We were considering implementing a Media:Photo resource that would have
> information such as:
> - MLS Number associated with this photo
> - Photo modification date
> - Photo md5sum
> - Photo caption
> - Photo position
> - Photo url
> 
> I suspect this is fairly non-standard and therefore it may not be used
> by many clients, but assuming many of the above fields are searchable it
> provides a way to do granular incremental searches on objects. It also
> provides a mechanism for somebody maintaining a photo repository to
> check that repository without having to download extra images by
> checking the entire repository against the md5sums. It also associates
> the photo caption info with each of the photos which I'm not sure is
> supported with GetObject.
> 
> I'd be interesting in hearing other solutions to this problem. I suspect
> there are many out there.
> 
> 
> Colby Ackerfield
> RealGo, Inc.
>