[Rets-dev] On Reference Implementations
JP Fielding
jp.fielding at threewide.com
Fri Mar 16 11:20:45 CDT 2007
also the java based cart client on sourceforget (cart.sf.net) is alive and
kicking. head of cvs contains the latest and greatest stable with support
for streaming searches, full meta support (now serializable to support
trivial metadata caching), getobject with multipart, ua-auth and even setup
to use gzip when servers support it (only 1 server ever offered that). it
works great with every vendor we've encountered.
On 3/16/07, Sergio Del Rio <Sergio.Del.Rio at t4bi.com> wrote:
>
> And I will also mention that there is a comprehensive suite of Java based
> tools (that have also been proven to be easily wrapped into .NET classes)
> that are freely available at:
>
> http://openrets.mris.com/
>
> Using the JRETSC interface, it takes less than a page of code to connect
> to
> ANY RETS server, issue the query, retrieve the data and pull the images
> whether the server provides simple URL's or images with the GetObject
> call.
>
> I built the JRETSC interface primarily to help my developers be more
> productive and not have to learn the in's and out's of RETS protocols, but
> we published it as open source on SourceForge to help all of the community
> more easily adopt RETS.
>
> I think this interface shows how truly easy it can be to build any RETS
> client that is also metadata aware.
>
> So, you see, there are tools out there, perhaps we need a better set of
> links on the RETS website to point to all the tools that are available.
>
> Regards,
> Sergio Del Rio
> Templates 4 Business Inc.
>
>
> -----Original Message-----
> From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
> Behalf
> Of Steve Verba
> Sent: March 16, 2007 5:57 AM
> To: 'Matt Lavallee'
> Cc: rets-dev at rets.org
> Subject: RE: [Rets-dev] On Reference Implementations
>
> Currently we have been operating for several years under exactly that
> position; no major change proposal or new version of the spec can get a
> final approval unless there are reference implementations - two in fact.
>
> There has been debate as to whether to relax this or modify it, but
> nonetheless that has been standard operating procedure for some time.
>
> Also worth noting for this thread is the fact that of the three real
> estate
> standards (RETS, MISMO, OSCRE/PISCES), RETS is the only one with a large
> body of open source tools, reference implementations, compliance checking
> code, POC's, utilities, etc. To be more precise, the other two standards
> have virtually none - a testimony to this community and to CRT and NAR,
> given that the MISMO and OSCRE communities are larger.
>
> Steve
>
> -----Original Message-----
> From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
> Behalf
> Of Matt Lavallee
> Sent: Friday, March 16, 2007 2:07 AM
> To: rets-dev at rets.org
> Subject: RE: [Rets-dev] On Reference Implementations
>
> For what it's worth, Frank, I raised exactly this issue during the last
> phone call. I suggested that no document is accepted before we have a
> reference implementation that proves it's viable.
>
> -Matt
>
> Paul Stusiak wrote:
> >
> > That's a very good point Frank. Let me see what I can do with that
> > idea.
> >
> > Frank Wanicka wrote:
> > > Ok, maybe "absurd" is overstating things, but if someone had put
> > > together a simple standalone app that could retrieve data and
> > > photos at some point, maybe RETS adoption would have moved along
> > > more quickly. Should the RETS community feel obligated to create
> > > one? No, I guess not. Does common sense suggest it might be a
> > > good idea if you're not happy with the rate at which your
> > > standard is being adopted? I think so. This isn't the first
> > > time I've seen this request on the list, and surely there are
> > > many others out there with the same need that don't subscribe to
> > > the list.
> > >
> > > _________________
> > > Frank Wanicka
> > > Real Estate Technologies, Inc.
> > >
>
>
>
> _______________________________________________
> Rets-dev mailing list
> 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
>
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070316/ed7b23f5/attachment-0001.html
More information about the Rets-dev
mailing list