[libRETS-users] Re: Problem with libRETS

[Matt Lavallee]

On  Wednesday, June 06, 2007 at 10:14 AM, Keith T. Garner wrote:

> On 6/6/07 10:02 AM, Matt Lavallee wrote:
> > For what it's worth, RETS is really less-than-ideal as a client/server
> > application protocol.  It's really chatty, and the MLS probably won't
> > appreciate concurrent logins (if they even allow it).
> 
> It truly depends on the MLS.  And often its not concurrent logins that is
> the problem but "real-time access."

I took the cue that a status-bar login indicator is a strong sign that it's a
real-time client... presumably it wouldn't be written for one person, either. :)

> > You should probably look at something like MRIS' Conduit and then write
> > your app as client/server against the returned data using native .NET
> > System.Data classes.  RETS and libRETS are a bit of an advanced topic
> > given that they're not native to .NET or the overall paradigm of .NET
> > programming conventions.
> 
> While it is not .NET native, it is not necessarily a sign that it shouldn't
> be used.  But I'm biased against reinventing wheels.

Certainly not; but because of how much if it is unmanaged (and, therefore,
undebuggable from the IDE), I wouldn't recommend it for the average linecoder.
Debugging with libRETS is more about tracing and referring to the logging
delegate than the usual .NET conventions with breakpoints, locals, watches,
profiling, etc.  From the IDE, any code that runs unmanaged basically sends and
receives data from the ether.

> In any case, Luke's original question seemed to be more about C# GUI
> programming and not about libRETS, and somewhat outside the scope of
> the librets-users mailing list.

True enough.

-Matt