[Rets-dev] On bandwidth

[Paul Stusiak]

While this is a great discussion, I think that this is more an 
implementation issue rather than a standards issue.

The points are very valuable for anyone looking at dealing with 
pictures. Separating the concerns and making use of some of the features 
of HTTP sounds like a very good architecture.

Paul

Chris McKeever wrote:
>
>     <aside>
>     it would be interesting to see what the comparative bandwidth
>     costs would be to the mls's just having a public (opt in per
>     broker) photo server, that is programatically predictable, that
>     allows people to link to it 'as needed'.   the cost of pulling
>     _every_ photo (by multiple users) would likely be a _LOT_ less if
>     instead, only interesting photos were pulled.  servers could
>     provide links instead of the actual photo (see the optional
>     location option of rets 1.x,  im only aware of marketlinx (the
>     original) supporting this, although the urls are only partially
>     predictable).  even then, most web servers can be setup to
>     optimize caching options so no users need not pull it more than
>     once.  (currently doing something similar with a web based photo
>     server that proxies on the fly to multiple rets servers, caching
>     rets get object responses and sending all possible http response
>     caching headers).
>     </aside>
>
>
>
> I love the concept of a public photo server - MLSNI has one, and we 
> rolled our own at PRU...it solves ton of issues outside of the 
> bandwidth  concerns.
>
>  
>
>     On 5/1/07, *Matt Lavallee* < matt at pmptechnology.com
>     <mailto:matt at pmptechnology.com>> 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
>
>          
>
>         pmpt_logo
>
>         PMPTechnology.com <http://www.pmptechnology.com/>
>
>         	
>
>         *Matt Lavallee*
>         /Manager of Web Services/
>
>         /phone:/ 630-598-2301
>         /fax:/ 630-982-6641
>
>          
>
>          
>
>
>         _______________________________________________
>         Rets-dev mailing list
>         Rets-dev at rets.org <mailto:Rets-dev at rets.org>
>         http://lists.rets.org/mailman/listinfo/rets-dev
>
>
>
>     _______________________________________________
>     Rets-dev mailing list
>     Rets-dev at rets.org <mailto:Rets-dev at rets.org>
>     http://lists.rets.org/mailman/listinfo/rets-dev
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev
>   

-- 
Paul Stusiak
Falcon Technologies Corp.