Re: Helma XML-RPC @ Jakarta
On Wednesday, July 4, 2001, at 05:19 AM, Ian Kallen [EMAIL PROTECTED] wrote: My unsolicited opinion: projects focused on the manipulation and purveyance of data as XML could/should belong in the xml.apache.org project while implementations of Java technologies associate with Jakarta. (BTW this is a general response rather than an opinion about Helma XML-RPC) i believe that xml.apache.org has a strong emphasis on standards. that means that projects focused on the manipulation and purveyance of data as XML which are not standards-based will not necessarily find a home there. excluding projects from jakarta simply because they are xml-related would therefore seem to allow otherwise appropriate projects to 'fall through the cracks' between xml.apache.org and jakarta.apache.org. for what it's worth... what ever happened to the idea that was being floated about jakarta-xml common projects (or was it 'xml-jakarta-commons')? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Helma XML-RPC @ Jakarta
Hi there, I'm the author of the Helma XML-RPC library, and I'd like to deliver some background information as well as my personal view regarding the jakarta/xml dispute. To put it right upfront, I don't think XML-RPC is a natural fit for xml.apache.org, and I'd prefer to see it at Jakarta. Let me explain. XML-RPC is a protocol that has been explicitly frozen since 1998 or so, and even at that time it only used a small subset of XML. Sure, it has the XML in its name, but all it does is define a handful of elements to wrap some common data types - strings, numbers, date objects, structs and so on. No other elements may ever occur in XML-RPC, let alone any of the additional XML add-ons that have been spec'ed out since 1998. To see what I'm talking about have a look at the XML-RPC spec at http://www.xmlrpc.com/spec (if you like compare it to the SOAP spec for contrast). XML-RPC is not about XML, it just uses the minimum XML necessary to pass method calls and data between clients/servers. This means that coupling XML-RPC with a full featured XML environment may not have a lot of benefits - in fact, in my experience all it does is increase memory footprint and download size and decrease performance, simply because XML-RPC doesn't use any but the most primitive parsing facilities. So why Jakarta? One area is HTTP support - XML-RPC works over HTTP, and the code contains both an embedded HTTP server as well as a client and a servlet interface. I'd say most of the feature requests or questions I get revolve around HTTP or Servlet issues, and I definitely think that Jakarta is the ideal environment for this. Another hot development area may be to improve mapping between XML-RPC data types and Java objects. Since XML-RPC data types are carved in stone, there's practically no XML work going on here, but it will be very Java-specific. Of course, development can take place anywhere. I just don't see how XML-RPC would fit into the Apache XML project. If anybody actually does have a proposal please let me know. cheers, Hannes Von: robert burrell donkin [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Wed, 4 Jul 2001 20:13:07 +0100 An: [EMAIL PROTECTED] Betreff: Re: Helma XML-RPC @ Jakarta On Wednesday, July 4, 2001, at 05:19 AM, Ian Kallen [EMAIL PROTECTED] wrote: My unsolicited opinion: projects focused on the manipulation and purveyance of data as XML could/should belong in the xml.apache.org project while implementations of Java technologies associate with Jakarta. (BTW this is a general response rather than an opinion about Helma XML-RPC) i believe that xml.apache.org has a strong emphasis on standards. that means that projects focused on the manipulation and purveyance of data as XML which are not standards-based will not necessarily find a home there. excluding projects from jakarta simply because they are xml-related would therefore seem to allow otherwise appropriate projects to 'fall through the cracks' between xml.apache.org and jakarta.apache.org. for what it's worth... what ever happened to the idea that was being floated about jakarta-xml common projects (or was it 'xml-jakarta-commons')? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Helma XML-RPC @ Jakarta
Hannes Wallnoefer wrote: [snip] Short and simple: -1. Good luck getting 3/4 approval... Want to change my vote? Demonstrate some signs that you are willing to work with others, or are at least aware of related work. Criticize SOAP or the Apache implementation thereof if you like - I can take it. Start with introducing yourself on the [EMAIL PROTECTED] mailing list. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Helma XML-RPC @ Jakarta
On 7/4/01 10:04 PM, Sam Ruby [EMAIL PROTECTED] wrote: Hannes Wallnoefer wrote: [snip] Short and simple: -1. Good luck getting 3/4 approval... Want to change my vote? I don't think there's anything to change. You decided what you what you wanted very shortly after the proposal was made. That much is clear, even if your answers are not. I answered your questions as best I could, but you completely skirted around answering any of my questions. I asked what you would do with the code if it were brought into xml.apache.org and I wanted to know what the interest is in xml-rpc, and why no one has taken the steps to move toward an xml-rpc implementation in axis? Are these not valid questions and concerns? You are the one intimately involved with xml.apache.org, so I assume you could answer these questions quickly. Demonstrate some signs that you are willing to work with others, I have been working with Hannes and the initial committers for the last month to get to this point. I am interested in the xml-rpc package. You are being unequivocally evasive. I don't think you're being very cooperative. I asked what your proposal would be if the code was to be donated to xml.apache.org and you didn't even bother to answer. Is the answer supposed to be obvious? It's not obvious to me. I think it's important that the code comes here, we have our preferences as to the location but the code is used by a lot of people and it would be a healthy project at apache. or are at least aware of related work. I am aware of other xml-rpc packages, as I must emphasize that is what I'm interested in. Criticize SOAP or the Apache implementation thereof if you like - I can take it. I have absolutely nothing against SOAP, or your implementation of it. I haven't looked that much at SOAP because none of the projects I work on require it's use. To me, SOAP and xml-rpc are mutually exclusive because that is the nature of my work. If xml-rpc is to be a subset of axis than the real nature of the arrangement is that you need xml-rpc but we don't need axis. Start with introducing yourself on the [EMAIL PROTECTED] mailing list. I have zero interest in axis at the moment. Why is the onus on me to participate in something in which I have no interest and no requirement to be involved with. The xml-rpc package works fine as a stand-alone piece of work. I am fully willing to work on the xml-rpc package, but I'm certainly not going to stop you from integrating the package into axis. I don't see why you see this as not cooperating, it is simply not the domain I work in. You can correct me if I'm wrong, but I think your proposal would be the folding of the xml-rpc code into axis and forcing users currently using xml-rpc by itself to use xml-rpc through axis instead. This is expressly something we do not desire. This is what I'm deducing from your emphasis on axis and lack of clear answers to very direct questions. What do you feel about the xml-rpc package being an independent project at xml.apache.org? As a starting point for cooperation between the xml-rpc package and axis. How is that for meeting half way? Then the the collaboration would begin as two autonomous parties. I would first like ask for votes from the Jakarta PMC members to see if the package can be included within Jakarta as this is the express desire of the author. I will make another short message with a voting form. If this fails than I will make a proposal to xml.apache.org if the package could be accepted as an independent project (if this is acceptable to Hannes). If the code is allowed to exist autonomously than I don't have a real problem with where it lands. But I definitely don't like the idea of the code being rolled into another package because right off the bat we would probably be in a minority situation and the code could go in a direction that we don't want. I don't believe that is right. But again Sam, correct me if my assertions are in the wrong. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
