on Thu, 17 Jul 2003 12:37:36 -0400 Ryan Hoegg <[EMAIL PROTECTED]>
wrote:
> I think one
> way we
> could accomplish the transport independence is to have the
> XmlRpcClient and XmlRpcServer classes send and receive messages as SAX
> events rather than bytes.
Great idea, additionally if SAX2 wer
John,
Your use case, like Rufios and like mine to a lesser extent, seems to
support
the abstraction of the transport layer. Just as Rufio's particular case
raised
some interesting issues (transporting XML rather than bytes) I'm sure yours
might as well. To what degree have you looked into the
These types of changes seem to me to be good for the library, because to
me the
XML messaging format and the transport are separate concerns. As we look
into how these goals might be attained within the code, we should be
careful to
identify the boundaries between the concerns appropriately. I
Hi
As John suggested these are changes that IMO would ease writng transport
plugins:
I think that the apache xmlrpc should be transport independant
framework, as such
- shouldn't have any http specific classes;
http classes should be moved to their own package
- shouldn't have any http specific
> [EMAIL PROTECTED] wrote:
> Guys. This can be done with sane XML-RPC request/response objects
> (think servlets) and an interceptor API, instead of creating N endpoint
> implementations.
In what way are XmlRpcRequest and XmlRpcClientRequest objects
not 'sane'?
Why is having n implementatio
Rufio,
I *am* using the Apache XML-RPC on the host side of the communications
channel. I've got mixed communication channels sometimes the Host == Server
and Target == Client, sometimes reversed, sometimes both.
I'll be following the Apache XML-RPC run-up to 2.0 and follow the CVS head,
as I thi
rufio wrote:
> on Thu, 17 Jul 2003 15:16:22 +0100 "John Wilson" <[EMAIL PROTECTED]>
> wrote:
>
>> rufio wrote:
[yet more stuf]
> I mentioned before that plugin should provide it's own Writer.
I don't see that in any message you posted to this thread
Perhaps it was mentioned in the private convers
on Thu, 17 Jul 2003 15:16:22 +0100 "John Wilson" <[EMAIL PROTECTED]>
wrote:
> rufio wrote:
>
> > I don't see your problem. All you have to do is split what changes
> > and what stay constant: generating string containing a XML messge is
> > constant so framework does that;
> > encoding may change
rufio wrote:
> on Thu, 17 Jul 2003 14:22:23 +0100 "John Wilson" <[EMAIL PROTECTED]>
> wrote:
>
>> rufio wrote:
>>> on Thu, 17 Jul 2003 07:44:01 +0100 "John Wilson" <[EMAIL PROTECTED]>
>>> wrote:
>>>
rufio wrote:
[more stuff]
> I don't see your problem. All you have to do is split what changes
on Thu, 17 Jul 2003 08:37:26 -0500 "Volkar, John"
<[EMAIL PROTECTED]> wrote:
> Just goes to show, nothing in the world is really new. I'll definitely
> be looking into it. But I'm not using java as the embedded side
> language, rather standard C and some C++ depending on the target
> environments
[EMAIL PROTECTED] wrote:
... long drawn out discussion over whether or how to implement a pluggable transport layer ...
*bangs head*
Guys. This can be done with sane XML-RPC request/response objects (think servlets) and an interceptor API, instead of creating N endpoint implementations. This hor
on Thu, 17 Jul 2003 14:22:23 +0100 "John Wilson" <[EMAIL PROTECTED]>
wrote:
> rufio wrote:
> > on Thu, 17 Jul 2003 07:44:01 +0100 "John Wilson" <[EMAIL PROTECTED]>
> > wrote:
> >
> >> rufio wrote:
> [stuf]
>
> You have not addressed the encoding issue.
You are talking about technical issues so I
John Wilson wrote:
> That's why I wrote MinML-RPC (http://www.wilson.co.uk/xml/minmlrpc.htm)
> which is a small footprint XML-RPC implementation which is currently
> being used for industrial process control and is running in Jacuzzis
> and toasters (really!).
Just goes to show, nothing in the
rufio wrote:
> on Thu, 17 Jul 2003 07:44:01 +0100 "John Wilson" <[EMAIL PROTECTED]>
> wrote:
>
>> rufio wrote:
[stuf]
You have not addressed the encoding issue. This is really a quite
fundamental problem with what you propose. If the XML generation code
doesn't generate an XML header then it needs
Volkar, John wrote:
> I can give a little insight as to why being able to "break" the spec
> in regards to transport layer is very desirable in some situations.
>
> I work with embedded systems and often times need a messaging or RPC
> style protocol. I don't know how many different times I've had
on Thu, 17 Jul 2003 13:55:16 +0200 "Andrew Evers"
<[EMAIL PROTECTED]> wrote:
> > You implement XML-RPC only in the default plugin, the rest is just a
> > framework, a code that does common things and if you support
> > different transports, putting the prolog into message isn't common,
> > because
I can give a little insight as to why being able to "break" the spec in
regards to transport layer is very desirable in some situations.
I work with embedded systems and often times need a messaging or RPC style
protocol. I don't know how many different times I've had to reimplement a
fairly low
> > Yes but this isn't XML-RPC and XML-RPC is what the Apache code is
> > supposed to implement.
>
> I thought the whole idea about abstracting the transport layer was
> breaking the spec.
The idea of abstracting the transport layer was to make it easier to work
with custom or different HTTP imple
on Thu, 17 Jul 2003 07:44:01 +0100 "John Wilson" <[EMAIL PROTECTED]>
wrote:
> rufio wrote:
> > You cannot assume that lower protocol doesn't use XML.
>
> Yes you can - that's what the XML-RPC specification says.
Abstraction of transport layer breaks the spec in general, cause we dont
have to us
19 matches
Mail list logo
