[Rets-dev] On bandwidth

[Matt Lavallee]

While most MLSes (probably) do not provide X,Y values, I think it's worth having
in the spec for the nudge of direction, since it is a very valuable piece of
information WRT client interpretation; likewise mime-type, filesize, etc.
Generally speaking, these are inexpensive data points to collect at the time of
insertion, but very expensive to interpolate.

Although I've heard that some servers do offer pre-thumbnailed photos, we
(clients) at MLSNI have to thumbnail the photos ourselves (or use the public
server, as Chris detailed).  Our service does go through the thumbnailing effort
for a few reasons, generating 3 additional sizes depending on the original
dimensions: x-large, large, medium, thumb.  While I wouldn't expect an MLS to
offer such varied sizes, it would be good if the spec could accommodate those
that do.  So perhaps my Thumbnail suggestion should more aptly be a collection
(of other MediaIDs) rather than a field.

Now, of course, this introduces some issue of querying.  While XPath could get
the smallest thumbnail quite easily, the SQL required to perform the same task
is a bit awkward and includes some extended, recursive statements.

-Matt

> -----Original Message-----
> From: Paul Stusiak [mailto:pstusiak at falcontechnologies.com]
> Sent: Tuesday, May 01, 2007 11:37 AM
> To: Matt Lavallee
> Cc: Rets-dev at rets.org
> Subject: Re: [Rets-dev] On bandwidth
> 
> While there are many possible optimizations, photo servers I have worked
> on before do not inspect the images for such useful values as the X and
> Y dimensions of the image. I'm not sure if such information would be
> available generally.
> 
> One thing that I have seen implemented and we may want to consider it,
> is to have a series of pre-scaled images to meet the purpose -
> thumbnails for a quickview or slide show, mid-sized for web viewing and
> higher-resolution images for printing or image-only inspection. Please
> share your experience with this - is this common in your location as
> well? Perhaps we should codify this into the standard.
> 
> The semantic discord should be resolved. Thanks for pointing this out.
> There was an effort made to make the Media package more than just about
> pictures, although the majority of the media will be pictures. I'll put
> it on my list of changes.
> 
> Paul
> 
> Matt Lavallee wrote:
> >
> > Having spoken to my MLS, I concede to Paul that their bandwidth
> > concerns lay more in the photo domain than in the data transport. To
> > that end, I think we should review the Picture/Media sections to add
> > as many query- and client-optimized fields as possible.
> >
> > Some examples:
> >
> > DateAdded
> > DateModified
> > FileSize
> > ResolutionX
> > ResolutionY
> > MediaType (enumeration of Picture/Tour/Video/Other, etc.)
> > MediaFormat (MIME type?)
> > Thumbnail (another media ID?)
> >
> > In this way, updating clients could optimally query:
> >
> > (Property.Media.DateAdded>DateAdd(day,-1,GetDate())
> > OR
> > Property.Media.DateModified>DateAdd(day,-1,GetDate()))
> > AND
> > Property.Media.MediaType=’Picture’
> >
> > I also notice that there seems to be semantic discord between
> > PictureID (implying a photo) and the Media schema (which asserts all
> > media, not just pictures).
> >
> > -Matt