[mythtv] MythSOAP Expressions Of Interest

[Adam Jenkins]

Yeah, I see your point.  The last thing you want to do is maintain logic in
multiple places, and, in regards to wire transfer, xml is extraordinarily
bulky...to be honest I completely didn't think of that.  

Would any of your concerns be less if the SOAP layer followed a delegate
model (think dumb wrapper)?  Perhaps even auto generated?  The logic behind
SOAP was simply to reduce the development load from an integration point of
view.

What are your thoughts if that were the direction?

-----Original Message-----
From: mythtv-dev-bounces at mythtv.org
[mailto:mythtv-dev-bounces at mythtv.org]On Behalf Of Isaac Richards
Sent: Monday, February 21, 2005 1:40 PM
To: Development of mythtv
Subject: Re: [mythtv] MythSOAP Expressions Of Interest


On Sunday 20 February 2005 09:35 pm, Adam Jenkins wrote:
> Good points.  I'd love to hear your thoughts in regards to these issues as
> I'm still lacking in knowledge.
>
> >>this would move to _requiring_ the backend to be running
>
> Would that be only if they wanted to use the integration (SOAP) layer, or
> all the time?

To me, it doesn't make any sense whatsoever to have multiple methods of 
getting at the same data.  If anything goes in, it has to be able to replace

the existing frontend<->backend protocol.  Multiple methods is just asking 
for multiple bugs.

> >>my concern is that SOAP (like anything using XML) adds a lot of
> >>size + parsing complexity
>
> In regards to parsing complexity, do you mean development or during
> runtime? As most SOAP binding systems these days are designed to be
> reasonably transparent to the implementing system, development time is
> relatively trivial (just supply a WSDL file and binding points).  In
> regards to runtime parsing, the soap toolkit from apache has acheived some
> really good benchmarks (they've upgrade to SAX).

Runtime parsing.

> With respect to size, are you talking memory footprint or actual
deployment
> size?  Would making it an optional module would help here?

Size of the wire protocol.  Only way to get it down to something reasonable,

really, is to add compression with just adds even _more_ time to how long it

takes to parse.  And as I said, I don't see the point of making it optional.

Isaac
_______________________________________________
mythtv-dev mailing list
mythtv-dev at mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20050221/54cea702/attachment.htm