[Rets-dev] 2.0 overhead redux (long)

[Paul Stusiak]

On 1.

I am confused by your use of metadata. Are you talking about the 
metadata transaction to get descriptions of the system or are you 
talking about the metadata represented by the element tags and schema?

Also, I suspect that offering additional services and value to the MLS 
and agents will make the issue of additional bandwidth acceptable.

On 2.
Apparently I didn't make myself clear at the meeting. More than once I 
made the point that we were working on streamlining schema and the model 
to meet the goal described. The goal was a modular set of schemas that 
could be used both as-is and to be extended in a standard way - using 
some of the base types. You have chosen one of the many spots where this 
has not been done yet.

The purpose of the meetings in May and June is to work on just that thing.

As was mentioned, if you want to help with that effort, there is plenty 
to do.

I, on the other hand, do want to talk about the schemas and the model. 
It is deficient at this point in time and I want to fix it.

Paul

Matt Lavallee wrote:
> Alright, without arguing point by point, here are my issues:
>
> 1. Bandwidth.  I acknowledge that I am in a very large MLS by comparison, so my
> payloads are equally large compared to the average MLS/client transaction.
> However, bandwidth is by no means free to anyone, and I doubt very many MLSes
> are equipped (or eager to hear about) a potential 30-50% increase in their RETS
> utilization.  My MLS (again, a high-water case) has two bonded T3s with very
> high utilization, and it is *not* a trivial cost to add another T3.  We (one of
> many client services in the area) burst against their pipes at 30Mb+/s.  Also, I
> heard talks of systems handling _millions_ of RETS transactions a day... even
> with a 30% (being generous) increase in overhead, that is not a marginal
> expense.  And "several-fold" means "several times as many" according to
> Webster's Dictionary.
>
> I didn't even mention the metadata sections because the metadata dictionary
> structure is similarly much, much larger than that of RETS 1.7.  While trivial
> in large payloads (100+ listings), it will be significant in small payloads
> where the metadata is the bulk of the transaction.
>
> 2. Data Model.  This is not a topic I can delve into in any pleasant way, since
> I tried to raise the point more than once on-list and got no response...  When I
> see BathsTotal, BathsThreeQuarter, BathsHalf, and BathsFull, I say that it's not
> very modeled.  Ideally, the presentation would be:
> <baths>
> 	<bath type="threequarter" level="0" />
> 	<bath type="half" level="1" />
> 	<bath type="full" level="2" />
> 	<bath type="full" level="2" MasterBath="true" WainscotMaterial="ceramic"
> />
> </bath>
>
> ... and "BathsTotal" would be a derivative formulation of the above.  Moreover,
> the semantics would be consistent and TotalBedrooms would appear with the same
> <object><function> notation.
>
> I could go on and on about the model that includes ListingProperty, Listing,
> Property, PropertySummary, ListingHistory, and ListingRecord being disparate
> schema describing a single entity, but I _really_ don't want to talk about the
> model.
>
> -Matt
>
>
>
>
>   

-- 
Paul Stusiak
Falcon Technologies Corp.