You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Daniel Rall <dl...@finemaltcoding.com> on 2002/11/21 23:06:10 UTC
Re: New release of Apache XML-RPC
Emir <em...@usask.ca> writes:
...
> Daniel Rall wrote:
> >
...
> > I made objectParsed() protected today. What's your use case for each?
> >
> Jxta xml-rpc library uses XmlRpc class (extends it), and uses
> objectParsed() (and parse() as well). The goal is to use Apache
> xmlrpc.jar without modification.
Certainly. Our goal as well. :-)
> But since objectParsed is not accessible, initial implementor
> changed the method to public and recompiled.
Since you're extending XmlRpc, and the method is now protected, this
should no longer be an issue with CVS HEAD.
> Another programmer tried to extend the package org.apache.xmlrpc to
> include jxta classes, but the problem is then inconsistency with
> package content. These were not very clean solutions to my mind.
I agree -- better to refactor the core framework to make it more
easily extensionable.
> What I am doing is replicating XmlRpc class within jxta xmlrpc
> package, so 2 other classes can extend it with objectParsed(). This
> seems like a best solution to me now, since it allows for use of
> apache library in the original form. I see that you are making some
> major changes to the apache library.
Yes, but at the same time it will remain as backwards compatible as
possible.
> If you decide to make objectParsed accessible outside of package
> maybe, it would allow for easier extensions by users.
It is, as of my last email. :-)
> You probably had the similar thing in mind with *Processor classes.
> Thank you for the updates, I will see what I can do in jxta. I can
> foresee another major overhaul of jxta xmlrpc once the apache
> library releases new version. Some concepts you are developing like
> standalone *Worker and *Processor classes are what we alredy use in
> jxta.
Great! Good to know that the use case is already being applied.
> As far as the DateTool is concerned, jxta classes would also use it, as
> they extend XmlRpc.
I have moved it into a util sub-package and made it public -- it is
now org.apache.xmlrpc.util.DateTool.
This issues that you've brought up so far are now taken care of.
Please let us know what other tweaks would make the library more
easily embeddable -- this is an important use case for most of us.
Also, if you plan on adopting CVS HEAD, let me know and I will slap
another tag on the repository.
> > > I am trying to make a jxta xml-rpc package that uses org.apache.xmlrpc,
> > > but I have to copy a lot of stuff just because of visibility.
> >
> > Let's see what we can do about that. Shall we move this discussion to
> > the rpc-dev@xml.apache.org list? Folks there are quite receptive to
> > enhancment requests.
> Maybe later, when I manage to figure out everything what we need to
> adapt the jxta to xmlrpc. I will then subscribe.
Looking forward to hearing from you.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: New release of Apache XML-RPC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Andrew Evers" <ae...@redwood.nl> writes:
> > This issues that you've brought up so far are now taken care of.
> > Please let us know what other tweaks would make the library more
> > easily embeddable -- this is an important use case for most of us.
> > Also, if you plan on adopting CVS HEAD, let me know and I will slap
> > another tag on the repository.
>
> On the subject of tagging things, I would like to commit the transport
> independence changes I've been working on to the client code somewhere,
> in order to keep the ball rolling. I would prefer to commit them to
> HEAD if possible, but I'm willing to put them on an CLIENT_NG branch
> or similar.
>
> Most of the work is in making it easier to work with the client without
> having to use Vectors and Strings, and to separate the XML-RPC and HTTP
> layers on the client side as much as possible.
>
> The code is now quite well tested, as it is integrated into our system
> here, so, it really needs to be reviewed for acceptance more than
> tested (although extra testing is always good).
If you think it's ready for CVS HEAD, +1 on commit then review.
Otherwise, let's put it in a branch. In any case, I'm looking forward
to seeing it in CVS.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: New release of Apache XML-RPC
Posted by josh lucas <jo...@stonecottage.com>.
On Tuesday, December 3, 2002, at 08:34 PM, Ryan Hoegg wrote:
> Daniel Rall wrote:
>
>> "Andrew Evers" <ae...@redwood.nl> writes:
>>
>>> Well, it depends on whether we will use a branch or a tag. I'd prefer
>>> not to use a branch, bit I don't really mind which. If there is any
>>> debate, let it be now (I think you guys are awake now, since it's
>>> evening here). If I don't hear anything I will tag whatever's in CVS
>>> with the next sensible pre tag and then commit all I have to HEAD. I
>>> can always back it out later ;)
>>>
>>
>> Depending upon the size of your change, let's either tag what's there
>> as XMLRPC_1_2_A3, or branch it as XMLRPC_1_2_BRANCH and call the next
>> release 2.0. Either way, you're free to work in HEAD. How big are
>> your changes? Do they warrant a major point release?
>>
>
> At this point we have several new features coming in:
> - abstracted transport
> - abstracted logging
> - subpackage reorganization and cleanup, possibly resulting in several
> JAR alternatives for our users
> - possibly the introspection and interceptors patch?
> - possibly Mavenizing the build and website
>
> If we end up with this many new features, I would call that a major
> point release.
>
> Would you guys comment on the above features? Anything in there you
> would rather we didn't do? Anything I missed? Anything need more
> explanation?
>
Going by the above features, I think a major point release would be
warranted especially if we are going offer various jars for people to
grab.
josh
Re: New release of Apache XML-RPC
Posted by josh lucas <jo...@stonecottage.com>.
On Tuesday, December 3, 2002, at 08:34 PM, Ryan Hoegg wrote:
> Daniel Rall wrote:
>
>> "Andrew Evers" <ae...@redwood.nl> writes:
>>
>>> Well, it depends on whether we will use a branch or a tag. I'd prefer
>>> not to use a branch, bit I don't really mind which. If there is any
>>> debate, let it be now (I think you guys are awake now, since it's
>>> evening here). If I don't hear anything I will tag whatever's in CVS
>>> with the next sensible pre tag and then commit all I have to HEAD. I
>>> can always back it out later ;)
>>>
>>
>> Depending upon the size of your change, let's either tag what's there
>> as XMLRPC_1_2_A3, or branch it as XMLRPC_1_2_BRANCH and call the next
>> release 2.0. Either way, you're free to work in HEAD. How big are
>> your changes? Do they warrant a major point release?
>>
>
> At this point we have several new features coming in:
> - abstracted transport
> - abstracted logging
> - subpackage reorganization and cleanup, possibly resulting in several
> JAR alternatives for our users
> - possibly the introspection and interceptors patch?
> - possibly Mavenizing the build and website
>
> If we end up with this many new features, I would call that a major
> point release.
>
> Would you guys comment on the above features? Anything in there you
> would rather we didn't do? Anything I missed? Anything need more
> explanation?
>
Going by the above features, I think a major point release would be
warranted especially if we are going offer various jars for people to
grab.
josh
Re: New release of Apache XML-RPC
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>"Andrew Evers" <ae...@redwood.nl> writes:
>
>
>>Well, it depends on whether we will use a branch or a tag. I'd prefer
>>not to use a branch, bit I don't really mind which. If there is any
>>debate, let it be now (I think you guys are awake now, since it's
>>evening here). If I don't hear anything I will tag whatever's in CVS
>>with the next sensible pre tag and then commit all I have to HEAD. I
>>can always back it out later ;)
>>
>>
>
>Depending upon the size of your change, let's either tag what's there
>as XMLRPC_1_2_A3, or branch it as XMLRPC_1_2_BRANCH and call the next
>release 2.0. Either way, you're free to work in HEAD. How big are
>your changes? Do they warrant a major point release?
>
>
At this point we have several new features coming in:
- abstracted transport
- abstracted logging
- subpackage reorganization and cleanup, possibly resulting in several
JAR alternatives for our users
- possibly the introspection and interceptors patch?
- possibly Mavenizing the build and website
If we end up with this many new features, I would call that a major
point release.
Would you guys comment on the above features? Anything in there you
would rather we didn't do? Anything I missed? Anything need more
explanation?
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: New release of Apache XML-RPC
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>"Andrew Evers" <ae...@redwood.nl> writes:
>
>
>>Well, it depends on whether we will use a branch or a tag. I'd prefer
>>not to use a branch, bit I don't really mind which. If there is any
>>debate, let it be now (I think you guys are awake now, since it's
>>evening here). If I don't hear anything I will tag whatever's in CVS
>>with the next sensible pre tag and then commit all I have to HEAD. I
>>can always back it out later ;)
>>
>>
>
>Depending upon the size of your change, let's either tag what's there
>as XMLRPC_1_2_A3, or branch it as XMLRPC_1_2_BRANCH and call the next
>release 2.0. Either way, you're free to work in HEAD. How big are
>your changes? Do they warrant a major point release?
>
>
At this point we have several new features coming in:
- abstracted transport
- abstracted logging
- subpackage reorganization and cleanup, possibly resulting in several
JAR alternatives for our users
- possibly the introspection and interceptors patch?
- possibly Mavenizing the build and website
If we end up with this many new features, I would call that a major
point release.
Would you guys comment on the above features? Anything in there you
would rather we didn't do? Anything I missed? Anything need more
explanation?
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: New release of Apache XML-RPC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Andrew Evers" <ae...@redwood.nl> writes:
> > OK, so I got my system hitting the repository over SSH, but it doesn't
> > look like the code Andrew sent me has been committed yet. Some of it
> > is there but theres no new branch and XmlRpcClient is still the old
> > version at least.
> >
> > Should I make a branch with the zip or wait for you to put it up
> > Andrew?
>
> Well, it depends on whether we will use a branch or a tag. I'd prefer
> not to use a branch, bit I don't really mind which. If there is any
> debate, let it be now (I think you guys are awake now, since it's
> evening here). If I don't hear anything I will tag whatever's in CVS
> with the next sensible pre tag and then commit all I have to HEAD. I
> can always back it out later ;)
Depending upon the size of your change, let's either tag what's there
as XMLRPC_1_2_A3, or branch it as XMLRPC_1_2_BRANCH and call the next
release 2.0. Either way, you're free to work in HEAD. How big are
your changes? Do they warrant a major point release?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: New release of Apache XML-RPC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Andrew Evers" <ae...@redwood.nl> writes:
> > OK, so I got my system hitting the repository over SSH, but it doesn't
> > look like the code Andrew sent me has been committed yet. Some of it
> > is there but theres no new branch and XmlRpcClient is still the old
> > version at least.
> >
> > Should I make a branch with the zip or wait for you to put it up
> > Andrew?
>
> Well, it depends on whether we will use a branch or a tag. I'd prefer
> not to use a branch, bit I don't really mind which. If there is any
> debate, let it be now (I think you guys are awake now, since it's
> evening here). If I don't hear anything I will tag whatever's in CVS
> with the next sensible pre tag and then commit all I have to HEAD. I
> can always back it out later ;)
Depending upon the size of your change, let's either tag what's there
as XMLRPC_1_2_A3, or branch it as XMLRPC_1_2_BRANCH and call the next
release 2.0. Either way, you're free to work in HEAD. How big are
your changes? Do they warrant a major point release?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: New release of Apache XML-RPC
Posted by Andrew Evers <ae...@redwood.nl>.
> OK, so I got my system hitting the repository over SSH, but it doesn't
> look like the code Andrew sent me has been committed yet. Some of it
> is there but theres no new branch and XmlRpcClient is still the old
> version at least.
>
> Should I make a branch with the zip or wait for you to put it up
> Andrew?
Well, it depends on whether we will use a branch or a tag. I'd prefer
not to use a branch, bit I don't really mind which. If there is any
debate, let it be now (I think you guys are awake now, since it's
evening here). If I don't hear anything I will tag whatever's in CVS
with the next sensible pre tag and then commit all I have to HEAD. I
can always back it out later ;)
Andrew.
Re: New release of Apache XML-RPC
Posted by Andrew Evers <ae...@redwood.nl>.
> OK, so I got my system hitting the repository over SSH, but it doesn't
> look like the code Andrew sent me has been committed yet. Some of it
> is there but theres no new branch and XmlRpcClient is still the old
> version at least.
>
> Should I make a branch with the zip or wait for you to put it up
> Andrew?
Well, it depends on whether we will use a branch or a tag. I'd prefer
not to use a branch, bit I don't really mind which. If there is any
debate, let it be now (I think you guys are awake now, since it's
evening here). If I don't hear anything I will tag whatever's in CVS
with the next sensible pre tag and then commit all I have to HEAD. I
can always back it out later ;)
Andrew.
Re: New release of Apache XML-RPC
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
OK, so I got my system hitting the repository over SSH, but it doesn't
look like the code Andrew sent me has been committed yet. Some of it is
there but theres no new branch and XmlRpcClient is still the old version
at least.
Should I make a branch with the zip or wait for you to put it up Andrew?
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Andrew Evers wrote:
>>This issues that you've brought up so far are now taken care of.
>>Please let us know what other tweaks would make the library more
>>easily embeddable -- this is an important use case for most of us.
>>Also, if you plan on adopting CVS HEAD, let me know and I will slap
>>another tag on the repository.
>>
>>
>
>On the subject of tagging things, I would like to commit the transport
>independence changes I've been working on to the client code somewhere,
>in order to keep the ball rolling. I would prefer to commit them to
>HEAD if possible, but I'm willing to put them on an CLIENT_NG branch
>or similar.
>
>Most of the work is in making it easier to work with the client without
>having to use Vectors and Strings, and to separate the XML-RPC and HTTP
>layers on the client side as much as possible.
>
>The code is now quite well tested, as it is integrated into our system
>here, so, it really needs to be reviewed for acceptance more than
>tested (although extra testing is always good).
>
>Andrew.
>
Re: New release of Apache XML-RPC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Andrew Evers" <ae...@redwood.nl> writes:
> > This issues that you've brought up so far are now taken care of.
> > Please let us know what other tweaks would make the library more
> > easily embeddable -- this is an important use case for most of us.
> > Also, if you plan on adopting CVS HEAD, let me know and I will slap
> > another tag on the repository.
>
> On the subject of tagging things, I would like to commit the transport
> independence changes I've been working on to the client code somewhere,
> in order to keep the ball rolling. I would prefer to commit them to
> HEAD if possible, but I'm willing to put them on an CLIENT_NG branch
> or similar.
>
> Most of the work is in making it easier to work with the client without
> having to use Vectors and Strings, and to separate the XML-RPC and HTTP
> layers on the client side as much as possible.
>
> The code is now quite well tested, as it is integrated into our system
> here, so, it really needs to be reviewed for acceptance more than
> tested (although extra testing is always good).
If you think it's ready for CVS HEAD, +1 on commit then review.
Otherwise, let's put it in a branch. In any case, I'm looking forward
to seeing it in CVS.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: New release of Apache XML-RPC
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
OK, so I got my system hitting the repository over SSH, but it doesn't
look like the code Andrew sent me has been committed yet. Some of it is
there but theres no new branch and XmlRpcClient is still the old version
at least.
Should I make a branch with the zip or wait for you to put it up Andrew?
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Andrew Evers wrote:
>>This issues that you've brought up so far are now taken care of.
>>Please let us know what other tweaks would make the library more
>>easily embeddable -- this is an important use case for most of us.
>>Also, if you plan on adopting CVS HEAD, let me know and I will slap
>>another tag on the repository.
>>
>>
>
>On the subject of tagging things, I would like to commit the transport
>independence changes I've been working on to the client code somewhere,
>in order to keep the ball rolling. I would prefer to commit them to
>HEAD if possible, but I'm willing to put them on an CLIENT_NG branch
>or similar.
>
>Most of the work is in making it easier to work with the client without
>having to use Vectors and Strings, and to separate the XML-RPC and HTTP
>layers on the client side as much as possible.
>
>The code is now quite well tested, as it is integrated into our system
>here, so, it really needs to be reviewed for acceptance more than
>tested (although extra testing is always good).
>
>Andrew.
>
Re: New release of Apache XML-RPC
Posted by Andrew Evers <ae...@redwood.nl>.
> This issues that you've brought up so far are now taken care of.
> Please let us know what other tweaks would make the library more
> easily embeddable -- this is an important use case for most of us.
> Also, if you plan on adopting CVS HEAD, let me know and I will slap
> another tag on the repository.
On the subject of tagging things, I would like to commit the transport
independence changes I've been working on to the client code somewhere,
in order to keep the ball rolling. I would prefer to commit them to
HEAD if possible, but I'm willing to put them on an CLIENT_NG branch
or similar.
Most of the work is in making it easier to work with the client without
having to use Vectors and Strings, and to separate the XML-RPC and HTTP
layers on the client side as much as possible.
The code is now quite well tested, as it is integrated into our system
here, so, it really needs to be reviewed for acceptance more than
tested (although extra testing is always good).
Andrew.
Re: New release of Apache XML-RPC
Posted by Andrew Evers <ae...@redwood.nl>.
> This issues that you've brought up so far are now taken care of.
> Please let us know what other tweaks would make the library more
> easily embeddable -- this is an important use case for most of us.
> Also, if you plan on adopting CVS HEAD, let me know and I will slap
> another tag on the repository.
On the subject of tagging things, I would like to commit the transport
independence changes I've been working on to the client code somewhere,
in order to keep the ball rolling. I would prefer to commit them to
HEAD if possible, but I'm willing to put them on an CLIENT_NG branch
or similar.
Most of the work is in making it easier to work with the client without
having to use Vectors and Strings, and to separate the XML-RPC and HTTP
layers on the client side as much as possible.
The code is now quite well tested, as it is integrated into our system
here, so, it really needs to be reviewed for acceptance more than
tested (although extra testing is always good).
Andrew.