[Rets-dev] On bandwidth

[Paul Stusiak]

in-line

Matt Lavallee wrote:
> 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.
>
>   
Unfortunately, on production servers, the introspection is fairly 
expensive. While I agree that this is a useful thing and it possibly 
should go in the standard, we might find that it is not populated in 
many cases. I'll include it, but I suspect that it will be empty in many 
cases.

> 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.
>
>   
Where were you when XPath was discussed :-)

I'm not sure what your concern with the querying is. Please expand on 
your concern.

> -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 
>>>       
>
>
>
>
>
>   

-- 
Paul Stusiak
Falcon Technologies Corp.