Title: RE: [mythtv] MythSOAP Expressions Of Interest

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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]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
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Important notice: This message is intended for the individual(s) and entity(s) addressed. The information contained in this transmission and any attached, may be confidential and may also be the subject of legal privilege, public interest immunity or legal professional privilege. Any review, retransmission, dissemination or other use of, taking of any action in reliance upon this information by person or entities other than the recipient is prohibited and requires authorization from the sender. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person) you may not copy or deliver this message to anyone. In such cases you should destroy this message and kindly notify the sender by reply email.

WARNING: Although Infocomp has taken reasonable precautions so that no viruses are present in this e-mail, the company cannot accept responsibility for any loss or damage arising from the use of e-mail attachments.

_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Reply via email to