Re: File Uploading using HttpClient
Not sure what you are saying here, Gluck. Can you explain? I personally see these two implementations as competing applications. Michael McGrady Ortwin Glück wrote: IndianAtTech wrote: OK, Thanks for the Information. I have found FileUpload API from Jakarta commons project Why do we have 2 API for Uploading from Same project 1. MultipartFileUpload - (Jakarta-commons)HttpClient - Project This is a client side interface to upload to a server. 2. FileUpload - (Jakarta Commons) This is a server side interface to consume the uploaded file. Or, Is there any conceptual difference between two API?? Yes. See above. - 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: 'Socket closed' exception using
How are you setting your headers? That is sometimes the issue on socket closings. At 10:25 AM 5/12/2004, Preygel, Sofya wrote: Hello, We are trying to use HTTPClient.execute(PostMethod) for sending SOAP requests to Connotate's Web Mining Server (WMS). The requests are sent every 1 minute, and in most cases everything works fine. However, every so often (sometimes way too often!) we are getting the 'Socket closed' exception. The socket timeout was initially set to 10 seconds (1 millis), but even after I set it to 120 seconds (12 millis), we are still seeing it happening quite often. I tried to use both the getResponseBodyAsString() and getResponseBodyAsStream() to retrieve the response, but it does not change anything. The application is running on Windows 2000 (SP4). I tried both the HTTPClient v2.0 (final) and the latest night build (as of yesterday), but the results are the same. We are using HTTP 1.0 (PostMethod.setHttp11(false)), with the application running on the same computer as the WMS. I will appreciate any suggestions about what can be done here. Thank you, Sofya Stack trace: 08:54:37 DEBUG [Thread-19] - enter PostMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter EntityEnclosingMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter getContentCharSet( Header contentheader ) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parse(String) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - Using buffered request body 08:54:37 DEBUG [Thread-19] - enter HttpConnection.getRequestOutputStream() 08:54:37 DEBUG [Thread-19] - Request body sent 08:54:37 DEBUG [Thread-19] - enter HttpConnection.flushRequestOutputStream() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.releaseConnection() 08:54:37 ERROR [Thread-19] - I/O exception executing the get data request 'Execute'. java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(H ttpConnection.java:1368) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127) at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(Ht tpConnection.java:799) at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase .java:2324) at org.apache.commons.httpclient.HttpMethodBase.processRequest(HttpMethodBa se.java:2657) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java :1093) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:6 75) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:5 29) at pbf.travinfo.dcol.CHPDI.AgentLibrary.getSOAPResponse(AgentLibrary.java:6 48) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 'Socket closed' exception using
I meant how do you set the response headers? That is probably where the problem is. At 10:32 AM 5/12/2004, Preygel, Sofya wrote: Here it is: PostMethod post = new PostMethod(m_URL); post.setHttp11(false); post.setRequestHeader(Content-Length, Integer.toString(payload.toString().length())); post.setRequestHeader(Content-type, text/xml;charset=utf-8); post.setRequestHeader(Content-type, text/xml; charset=ISO-8859-1); post.setRequestHeader(SOAPAction, http://tempuri.org/action/Agent.; + action); post.setRequestContentLength(payload.toString().length()); post.setRequestBody(payload.toString()); I tried to also use keep-alive connection option (even though I know it makes little sense for HTTP 1.0), but to no avail. Thanks, Sofya -Original Message- From: Michael McGrady [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 1:29 PM To: Commons HttpClient Project Cc: [EMAIL PROTECTED]; Preygel, Sofya Subject: Re: 'Socket closed' exception using How are you setting your headers? That is sometimes the issue on socket closings. At 10:25 AM 5/12/2004, Preygel, Sofya wrote: Hello, We are trying to use HTTPClient.execute(PostMethod) for sending SOAP requests to Connotate's Web Mining Server (WMS). The requests are sent every 1 minute, and in most cases everything works fine. However, every so often (sometimes way too often!) we are getting the 'Socket closed' exception. The socket timeout was initially set to 10 seconds (1 millis), but even after I set it to 120 seconds (12 millis), we are still seeing it happening quite often. I tried to use both the getResponseBodyAsString() and getResponseBodyAsStream() to retrieve the response, but it does not change anything. The application is running on Windows 2000 (SP4). I tried both the HTTPClient v2.0 (final) and the latest night build (as of yesterday), but the results are the same. We are using HTTP 1.0 (PostMethod.setHttp11(false)), with the application running on the same computer as the WMS. I will appreciate any suggestions about what can be done here. Thank you, Sofya Stack trace: 08:54:37 DEBUG [Thread-19] - enter PostMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter EntityEnclosingMethod.renerateRequestBody() 08:54:37 DEBUG [Thread-19] - enter getContentCharSet( Header contentheader ) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parse(String) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - enter HeaderElement.parsePair(char[], int, int) 08:54:37 DEBUG [Thread-19] - Using buffered request body 08:54:37 DEBUG [Thread-19] - enter HttpConnection.getRequestOutputStream() 08:54:37 DEBUG [Thread-19] - Request body sent 08:54:37 DEBUG [Thread-19] - enter HttpConnection.flushRequestOutputStream() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.close() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.closeSockedAndStreams() 08:54:37 DEBUG [Thread-19] - enter HttpConnection.releaseConnection() 08:54:37 ERROR [Thread-19] - I/O exception executing the get data request 'Execute'. java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.commons.httpclient.HttpConnection$WrappedOutputStream.write(H ttpConnection.java:1368) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127) at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(Ht tpConnection.java:799
Re: @author tags
+1 What are these social issues? I keep hearing the label but don't know the reality. Are they important? If people have troubles, let them have them. That's my take on that sort of thing. At 12:30 AM 3/16/2004, you wrote: Hello Eric, I was thinking about some kind of metrics, too. Not as advanced as yours, of course :-) But then I felt that a ranking is not the best approach. It may lure people to use tricks just to improve their ranking. There should be something that indicates the kind and volume of contributions, sure. Like that many mails, that many bug reports, and so on. But instead of trying to compute a ranking from it, I would prefer a randomized order, with the kind and volume of contributions listed for each person. Maybe with some hall of fame into which the major contributors can be voted. Somehow I feel that the social issues should not be tackled with a purely technical solution. cheers, Roland Eric Johnson [EMAIL PROTECTED] 15.03.2004 22:52 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: @author tags At the risk of adding fuel to an unproductive discussion, I thought I'd throw in my comments: [...snip...] Having noted some of the social issues, I do have to say that this mailing list has been very friendly and welcoming, and my compliments to everyone for keeping it that way. While not an entirely accurate measure, I have an urge to suggest a mathematical and statistical recognition metric, combining: * # of emails written to developer list * # of patches submitted * # of responses to bugzilla issues, wherein said person is not the reporter of the particular issue. * # of bugzilla issues reported, wherein reporting does not result in an INVALID categorization * negative points for each INVALID Bugzilla report (people wasting time and energy on behalf of the group) * Other contributions? My gut instinct is that some of these contributions should be weighted more than others, but seeing as this is a quagmire, I'm not sure I'd want to suggest what that weighting would be - at least not yet. The resulting number could be used to generate a ranking, and possibly a weighting of each contributor. With each release, the tally should be accumulated for some time period prior to that release (6 months?), and those people should be recognized in the release notes, and perhaps also on the web site. Such a metric would at least be an improvement over what we have now. It would at least recognize people who do nothing more than track down bugs. It would also give us some visibility into the size and involvement of the HttpClient community. Darts welcome! -Eric. Michael Becke wrote: The ASF has recently recommended that we discontinue use of @author tags. When first starting out I always enjoyed seeing my name in lights, though I do agree with the ASF's opinion on this matter. If we come to a consensus to remove @authors I suggest that we remove them from all existing code, as well as leave them out of new additions. Any comments? Mike Begin forwarded message: ASF Board Summary for February 18, 2004 snip - author tags are officially discouraged. these create difficulties in establishing the proper ownership and the protection of our committers. there are other social issues dealing with collaborative development, but the Board is concerned about the legal ramifications around the use of author tags - it is quite acceptable and encouraged to recognize developers' efforts in a CHANGES file, or some other descriptive file which is associated with the overall PMC or release rather than individual files. snip - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags
Thanks, Roland! You are a balanced mind. Refreshing! I read the IBM and SCO complaint. There is nothing extra-ordinary about that. If someone were taking proprietary code and introducing it into open source, that would be something that should be stopped. The @author tags are not related to this sort of conduct, unless we were trying to hide this activity by not using the tags. The proper response to these shennanigans would be to discourage it openly and provide the best way we could to identify culprits. Truth, not fiction and not falsity, is the best defense in legal matters. At 12:30 AM 3/16/2004, you wrote: Hello Michael, I hope this mail is still readable once it is converted to text-only format... Fuel to this fire, I think, is fine. Why not talk it out? Primarily because this mailing list is not for legal discussion, and we'll never ever talk it out. You are a lawyer, most of us are not. Your views are founded in your knowledge of the law of the country you work in, while ours are based on news reports about seemingly nonsensical lawsuits filed in the US. You can't convince us because we don't have the background knowledge to verify your arguments. For my part, I believe that there will always be at least one lawyer that represents the opposite of your views, if paid enough money. That's why it takes judges to make verdicts, right? * Based on what I've read, Would you spell out what [you've] read to make you think this? What kind of allegations? What kind of analysis of code? How does this relate to ASF? You are too dark here. Let us know what you actually are thinking? www.groklaw.net should be a good starting point. I remember that one example of stolen code involves indentical comments that go back to a common code base from which both, the proprietary and the open source software, got the same code. Or something like that. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags
Hello, Roland, you wrote: Your views are founded in your knowledge of the law of the country you work in, while ours are based on news reports about seemingly nonsensical lawsuits filed in the US. This is a media blitz that sells crap to the hoi polloi. The truth is that there are few cases filed that make no sense, and many cases filed that do make sense but are made to look strange by the media. You can't convince us because we don't have the background knowledge to verify your arguments. For my part, I believe that there will always be at least one lawyer that represents the opposite of your views, if paid enough money. That's why it takes judges to make verdicts, right? Judge only decide the law. Juries make verdicts. The idea that law is so flexible, like a debating class is not true. Only a few attorneys, and usually really good ones making a legitimate point, try to extend the law beyond its present boundaries. Judges are bound to use precedent, which means that such original arguments can only be changed ultimately in the appellate courts. All courts in the U.S., further, have clear rules which allow the courts to punish people who file dumb lawsuits, along with their lawyers. www.groklaw.net should be a good starting point. I remember that one example of stolen code involves indentical comments that go back to a common code base from which both, the proprietary and the open source software, got the same code. Or something like that. Thanks, again, for this. I see nothing startling or requiring a change in this sort of suit. That does not seem frivolous or related to the @author tags in a negative way to me.
RE: @author tags
+1 At 06:11 AM 3/16/2004, you wrote: Eric, Roland, et al I am a little hesitant to have (some sort of) a formal ranking system due to (1) difficulty to keep it objective. It will inevitably require an arbiter, a someone whose opinion would be regarded as unbiased by the overwhelming majority of HttpClient regulars. To me, that would mean that such person should not be a committer or a contributor him/herself. Basically it would take Jeff Jandalf or someone of Jeff's calibre. I am not really sure Jeff would want to assume such a burden, and I simply can't think of anyone else not directly involved with HttpClient who could take such a role (2) difficulty to keep it up to date. Let us be realistic: we have difficulty to keep our changelog up to date, let alone such a delicate matter as a ranking system. (3) intention to keep HttpClient non-competitive. I do not think it is be a major revelation to say that most of us contribute to Apache Jakarta because we are willing to trade some of our free time and work for some recognition within the community of peers. Still, I do not want HttpClient to evolve (or degrade) into a racing competition of a sort. At the moment HttpClient is a delicate ecology that so far produced decent results. I really want to keep it that way. I think a simple extension to the existing changelog in a form of 'proposed by', 'inspired by', 'contributed by', 'verified by' 'helped by', 'tested by' clauses per major change/commit would be sufficient for the time being. Until the dust settles at the Jakarta PMC level Thoughts? Oleg -Original Message- From: Eric Johnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 14:29 To: Commons HttpClient Project Subject: Re: @author tags Roland Weber wrote: Hello Eric, I was thinking about some kind of metrics, too. Not as advanced as yours, of course :-) But then I felt that a ranking is not the best approach. It may lure people to use tricks just to improve their ranking. Too true. My perspective on this matter is colored by the fact that everyone on this mailing list is very open and complimentary to each other, so I have a hard time seeing that happen here. I certainly don't want to do anything that would change that environment. As with any useful metric, it would require refinement over time, to prevent spoofing (I hope this isn't ever necessary), and to adjust for the relative value of contributions (size of patch, for example). The point of the recognition, I think, is to provide a compliment and encouragement to any and all that contribute, not necessarily to perfectly correlate with some abstract notion of the value of contributions. If anything, my suggestion was intended to be more inclusive than what we do now. So perhaps as a refinement, then, take something like the ranking I suggested earlier, compute the order and then divide into three groups - high, medium, and low involvement (or four, with the bottom fourth not actually recognized officially?). This would prevent people from competing to be first in the ranking, as people would just be recognized by which group they fell into. There should be something that indicates the kind and volume of contributions, sure. Like that many mails, that many bug reports, and so on. But instead of trying to compute a ranking from it, I would prefer a randomized order, with the kind and volume of contributions listed for each person. Maybe with some hall of fame into which the major contributors can be voted. Somehow I feel that the social issues should not be tackled with a purely technical solution. After watching my spouse do grading of her student's papers, I think in the end there is always a necessary fudge factor involved in something that effectively looks like grading. That fudge factor that might push someone either up or down. For example, someone might come in late in a beta cycle with a key patch, and do so quickly, promptly, and correctly. Someone would have to invoke the judgement for an appropriate recategorization, perhaps the person doing the release? cheers, Roland -Eric. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
RE: @author tags
This is a really good idea, Oleg. I am surprised, frankly, that we allow people to use the @author tags without having signed the agreement first. That would be a real problem. At 06:21 AM 3/16/2004, you wrote: In an attempt to reach a conclusion in this seemingly never-ending and fruitless discussion I suggest that as of now we discontinue the use of @author for all contributions submitted by people who have not signed Apache CLA http://www.apache.org/licenses/#clas. That should address legal concerns expressed during the discussion regardless how justified or unjustified they are Mike, probably we should run a vote on this matter and get it over with. What do you think? Oleg -Original Message- From: Michael McGrady [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 23:29 To: Commons HttpClient Project Subject: Re: @author tags Fuel to this fire, I think, is fine. Why not talk it out? Why not share perspectives and information? I have some remarks about what you have said, that I hope are helpful, see infra: CAN ANYONE ACTUALLY IDENTIFY A SINGLE LEGAL ISSUE WITH USING AUTHOR TAGS? Even though I am a lawyer, and a good one, I think, I cannot identify such an issue. This is a myth, in my opinion. See in At 01:52 PM 3/15/2004, you wrote: At the risk of adding fuel to an unproductive discussion, I thought I'd throw in my comments: Legal: * IANAL, however, it strikes me that there is at least some small legal exposure in the @author tags. As a contributor of sorts, but not an official committer, there are certain documents that I/my company need not sign with respect to my contributions to ASF. The @author tag, unfortunately, adds some ambiguity back into the equation, insofar as I *could* appear to be a significant contributor even though the same level of paperwork may not be associatiated with my contributions. As a lawyer, none of this makes the least sense to me. However ambiguous or not these things are is not related to the existence or non-existence of legal issues. What legal exposure to you see and why? Nothing said here relates at all to any legal exposure. * Based on what I've read, it would appear that certain unnamed three letter companies are creating allegations based on the most superficial of analyses of code. May this be ASFs way of protecting the innocent from spurious supeonas? I'll grant that it is a very narrow margin of defense, nothing more, although one that apparently would defeat said unnamed three letter companies. Would you spell out what [you've] read to make you think this? What kind of allegations? What kind of analysis of code? How does this relate to ASF? You are too dark here. Let us know what you actually are thinking? Social: * Some people contribute merely by monitoring the mailing list and perhaps testing, sending in a wire log that helps to find a bug. Do we want to recognize those people as well? * Some contributions have been in the form of one-line patches that are not in unidiff format, and do not have an associated Bugzilla entry. Do we recognize them? * Since the @author tag is certainly at the moment somewhat arbitrary in its actual recognition, its continued use may currently discourage contribution to the extent that people feel like the community is short-changing their contribution. The @author tag does not rule out anything. So, the use of this tag could hardly be responsible for other things that are not done. I don't see, further, what is arbitrary about the @author tag. If used properly, it does what it is supposed to do. How is that arbitrary? Having noted some of the social issues, I do have to say that this mailing list has been very friendly and welcoming, and my compliments to everyone for keeping it that way. While not an entirely accurate measure, I have an urge to suggest a mathematical and statistical recognition metric, combining: * # of emails written to developer list I would suggest that this is not helpful. Some idiots have automatic emails sent when out of the office, for example. That hardly deserves merit. * # of patches submitted Doesn't this depend on whether the quality is good. Submissions are one thing. Reasonable submissions are another. * # of responses to bugzilla issues, wherein said person is not the reporter of the particular issue. Ibid. * # of bugzilla issues reported, wherein reporting does not result in an INVALID categorization Ibid. * negative points for each INVALID Bugzilla report (people wasting time and energy on behalf of the group) Again, this depends on the quality of the INVALID[ity] doesn't it? * Other contributions? My gut instinct is that some of these contributions should be weighted more than others, but seeing as this is a quagmire, I'm not sure
Re: @author tags
Fuel to this fire, I think, is fine. Why not talk it out? Why not share perspectives and information? I have some remarks about what you have said, that I hope are helpful, see infra: CAN ANYONE ACTUALLY IDENTIFY A SINGLE LEGAL ISSUE WITH USING AUTHOR TAGS? Even though I am a lawyer, and a good one, I think, I cannot identify such an issue. This is a myth, in my opinion. See in At 01:52 PM 3/15/2004, you wrote: At the risk of adding fuel to an unproductive discussion, I thought I'd throw in my comments: Legal: * IANAL, however, it strikes me that there is at least some small legal exposure in the @author tags. As a contributor of sorts, but not an official committer, there are certain documents that I/my company need not sign with respect to my contributions to ASF. The @author tag, unfortunately, adds some ambiguity back into the equation, insofar as I *could* appear to be a significant contributor even though the same level of paperwork may not be associatiated with my contributions. As a lawyer, none of this makes the least sense to me. However ambiguous or not these things are is not related to the existence or non-existence of legal issues. What legal exposure to you see and why? Nothing said here relates at all to any legal exposure. * Based on what I've read, it would appear that certain unnamed three letter companies are creating allegations based on the most superficial of analyses of code. May this be ASFs way of protecting the innocent from spurious supeonas? I'll grant that it is a very narrow margin of defense, nothing more, although one that apparently would defeat said unnamed three letter companies. Would you spell out what [you've] read to make you think this? What kind of allegations? What kind of analysis of code? How does this relate to ASF? You are too dark here. Let us know what you actually are thinking? Social: * Some people contribute merely by monitoring the mailing list and perhaps testing, sending in a wire log that helps to find a bug. Do we want to recognize those people as well? * Some contributions have been in the form of one-line patches that are not in unidiff format, and do not have an associated Bugzilla entry. Do we recognize them? * Since the @author tag is certainly at the moment somewhat arbitrary in its actual recognition, its continued use may currently discourage contribution to the extent that people feel like the community is short-changing their contribution. The @author tag does not rule out anything. So, the use of this tag could hardly be responsible for other things that are not done. I don't see, further, what is arbitrary about the @author tag. If used properly, it does what it is supposed to do. How is that arbitrary? Having noted some of the social issues, I do have to say that this mailing list has been very friendly and welcoming, and my compliments to everyone for keeping it that way. While not an entirely accurate measure, I have an urge to suggest a mathematical and statistical recognition metric, combining: * # of emails written to developer list I would suggest that this is not helpful. Some idiots have automatic emails sent when out of the office, for example. That hardly deserves merit. * # of patches submitted Doesn't this depend on whether the quality is good. Submissions are one thing. Reasonable submissions are another. * # of responses to bugzilla issues, wherein said person is not the reporter of the particular issue. Ibid. * # of bugzilla issues reported, wherein reporting does not result in an INVALID categorization Ibid. * negative points for each INVALID Bugzilla report (people wasting time and energy on behalf of the group) Again, this depends on the quality of the INVALID[ity] doesn't it? * Other contributions? My gut instinct is that some of these contributions should be weighted more than others, but seeing as this is a quagmire, I'm not sure I'd want to suggest what that weighting would be - at least not yet. The resulting number could be used to generate a ranking, and possibly a weighting of each contributor. With each release, the tally should be accumulated for some time period prior to that release (6 months?), and those people should be recognized in the release notes, and perhaps also on the web site. Such a metric would at least be an improvement over what we have now. It would at least recognize people who do nothing more than track down bugs. It would also give us some visibility into the size and involvement of the HttpClient community. Darts welcome! This is all a quagmire, I would suggest. I sure would not want to have to deal with this in any respect. It is like looking something up in the Yellow Pages. No one likes to do it and it is not good information except for those that simply have to
Re: @author tags
THE PRACTICAL ASPECT OF THIS DISCUSSION IS AT BEST DUBIOUS The use of @author tags has a lot more than ownership or braggadocio to recommend itself to us. When we see certain authors, then we know that we don't have to double check the code too much. We might even stop for that reason alone to see what they do. Other authors, maybe we do the opposite. This is not unimportant. We can also see where people are interested in or good at various aspects of coding. There are lots of reasons to know who did what and when as well as for what reason. There is no reason that has been given that I find at all persuasive to not know who coded something. The deliberate creation of ignorance about these matters should be suspicious to our common sense. THE LEGAL ASPECT IN THIS DISCUSSION IS JUST PLAIN MISTAKEN Roland Weber wrote: Right now, there is a company with three capital letters on the loose, which is suing other companies (including another one with three capital letters) for reasons that most of the open source community considers to be silly. But it may be an expensive and lengthy enterprise to prove in court that a silly thing is a silly thing. If removing author tags may reduce the risk of being sued, then rip them out. 1. There is no legal liability engendered by the @author tags. If there is, please indicate how so. Wild speculations about other suits is not helpful. 2. Any alternative to @author tags will face exactly the same legal liability. With respect to everyone involved in this decision to break something that is not broken, this is all really not very smart. Some of the best programmers in the world are on these lists. Unfortunately, some of the worst jail house lawyers are also on this list. The list needs to know that this is all legal baloney. There is NOTHING fixed or protected legally by doing something with the @author tags. Anyone who thinks so is simply way off beam. All this talk about legal liability is nothing but well-intentioned smoke and mirrors. There is NO REALITY to the legal aspect of this discussion. Please get a real decision on this by someone that knows what they are talking about in the legal arena or stop this wild speculating about legal matters. No one who is attributed through @author tags is legally liable for anything they should not be legally liable for and any workable alternative won't change the legal liability a bit. Please, if you are advocating a change for legal reasons, understand that you are just wrong, that you don't know what you are talking about in this case. This is really not even debatable. Okay? PLEASE identify a real problem rather than speculating about the legal arena generally. That is emotionally appealing but not helpful, in my opinion, even if well-intentioned. The bugaboo of having to hide reality because people can sue for any silly reason is great copy for inquiring minds that read newspaper rags, but it is, again, a silly way to behave in a responsible arena. This is almost identical to an argument that we should not use plumbing but should build outhouses because sewer pipes sometimes break. Don't screw the area of open source coding up over wild and inaccurate speculation about legal liability. If you want to harm the open source community, in my opinion, this is a good start.
Re: @author tags
Roland Weber and, then, Chris Lamprecht wrote: a silly thing is a silly thing. If removing author tags may reduce the risk of being sued, then rip them out. One reason cited for removing the @author tags is for legal protection -- and it's a good reason. But I don't see how removing @author tags can offer any legal protection, unless you also clean out the CVS logs (which store who committed each change to each file, down to the exact lines of code they changed). Not to mention the bugzilla database, this message forum, etc. It WOULD BE a good reason if there were a legal problem. There is not. However, as Chris Lamprecht correctly notes, any workable alternative would have exactly the same non-existent problems. This discussion has begun over a non-problem. It is bureaucracy gone haywire once again. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags
Roland Weber wrote: I don't see that either. But if some of the top Apache guys feel, believe or know otherwise, that's good enough for me. Know what? This has become a recreation of illusions and delusions. This is like Franz Kafka's book The Trial. There are vague and unsubstantiated reasons for changing the entire attribution structure of the open source community. This is not good thinking. If the only purpose of the tags is to feature contributor names in a prominent place - namely the source code - then the real question becomes whether we can achieve this goal in some other way with reasonable effort. This is NOT the only goal. That is not even close to accurate. Concerning the CVS log, you have to be aware that the committer is not always the contributor. A contributor may put a patch in bugzilla, which is then comitted by someone else. Well, in the paranoid sort of talk we are having, then the committer becomes subject to these imagined but unreal legal assaults. Indeed, where an author is hidden, the Foundation would become liable for a conspiracy of hiding the real culprits. This is all silly from a legal standpoint. In general, I don't believe that the removal of author tags is to disguise from where the code came. Rather, some people may be afraid to find their name in the author tag of code which has no longer anything to do with what they actually contributed long ago. This is yet another reason? This is also not right. The @author tags keep track of rather than obscure people's relation to existing code. The destruction of this useful device will create rather than solve anything akin to this imagined problem. Then it would become their problem to dig through the CVS logs, bugzilla, and the mailing list archives to prove that they are *not* the author. To whom? This is just imaginary. This is Alice in Wonderland thinking. Love yah, Roland, but this is not your shining hour. Really, there is no legal difficulty, but this recommendation might create one. Microsoft could not have come up with a better way to screw up the code.
Re: @author tags
Roland Weber wrote: The ASF has recently recommended that we discontinue use of @author tags. For me, that is reason enough to remove the author tags in the absence of better reasons to keep them. I trust the ASF implicitly to have discussed this matter thoroughly. If I didn't trust them, I'd search whether that discussion is documented online, possibly in some other mailing list. Well, I am not so sanguine. I can cite cases ad nauseum where responsible parties make mistakes on fundamental matters. This is just not a good idea on legal grounds. Maybe there is a less than obvious agenda that has nothing to do with legality. That is more likely, I would think. Someone got a link at hand? I would love to see this. -mikey
RE: @author tags
We all love Roland. No issue there. However, I really cannot see how the @author tag hides any contributions. Maybe on that issue I am lost? That is another matter altogether. I was discussing the legal ramifications solely. At 05:19 AM 3/12/2004, you wrote: Love yah, Roland, but this is not your shining hour. Actually Roland shines when it comes to giving feedback to proposed changes, patches, answering questions, and helping people on the mailing. He is precisely the reason I (as a HttpClient project committer) would like to have a better attribution structure that goes beyond @author tag. The @author may be a very misleading indicator of one's contribution and its value. Roland contribution is currently MASSIVELY understated within the existing attribution structure. As much as I would regret to see @author go, at the same time I would whole-heartedly welcome a better system of giving due credits to the regular contributors like Roland. If the board comes up with viable substitution to the @author tag, so be it Oleg -Original Message- From: Michael McGrady [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 13:38 To: Commons HttpClient Project Subject: Re: @author tags Roland Weber wrote: I don't see that either. But if some of the top Apache guys feel, believe or know otherwise, that's good enough for me. Know what? This has become a recreation of illusions and delusions. This is like Franz Kafka's book The Trial. There are vague and unsubstantiated reasons for changing the entire attribution structure of the open source community. This is not good thinking. If the only purpose of the tags is to feature contributor names in a prominent place - namely the source code - then the real question becomes whether we can achieve this goal in some other way with reasonable effort. This is NOT the only goal. That is not even close to accurate. Concerning the CVS log, you have to be aware that the committer is not always the contributor. A contributor may put a patch in bugzilla, which is then comitted by someone else. Well, in the paranoid sort of talk we are having, then the committer becomes subject to these imagined but unreal legal assaults. Indeed, where an author is hidden, the Foundation would become liable for a conspiracy of hiding the real culprits. This is all silly from a legal standpoint. In general, I don't believe that the removal of author tags is to disguise from where the code came. Rather, some people may be afraid to find their name in the author tag of code which has no longer anything to do with what they actually contributed long ago. This is yet another reason? This is also not right. The @author tags keep track of rather than obscure people's relation to existing code. The destruction of this useful device will create rather than solve anything akin to this imagined problem. Then it would become their problem to dig through the CVS logs, bugzilla, and the mailing list archives to prove that they are *not* the author. To whom? This is just imaginary. This is Alice in Wonderland thinking. Love yah, Roland, but this is not your shining hour. Really, there is no legal difficulty, but this recommendation might create one. Microsoft could not have come up with a better way to screw up the code. *** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *** - 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: @author tags
Does anyone have the recommendation or the reasoning? There seems to be a dirth of information on what they were thinking about. Just to assume that representatives of the various projects know more than the members of the projects about this issue is not a good way to go, in my opinion. Mike At 06:01 AM 3/12/2004, you wrote: Adrian, As far as I can see, the discussion is happening on many project lists, and on the pmc list. You would think [EMAIL PROTECTED] would be a better forum, but its quiet there. Because this is a board recomendation individual projects have to make their own dicisions on wether to implement it or not. HttpClients committers and community will have to decide to do this or not for HttpClient. As HttpClient is still part of Commons, this decision could be defered to all of Commons, but given HttpClients top level aspirations, I would encourage HttpClient to make this decision on its own. -jsd Adrian Sutton wrote: Hi all, I understand that people have a lot to say on this topic, however this is most definitely not the list to say it on. No one on this list has the legal authority to represent or make decisions on behalf of the ASF and this is an ASF decision. The recommendation that author tags not be used came down from the board of the ASF which does have the ability to make such decisions, nothing we say here will change that. I certainly don't intend to tell people not to voice their opinions on this matter, every decision in the ASF can potentially be reversed but such issues need to be taken to the ASF board or at least the PMC (the PMC is apparently already hotly debating this topic). My biggest problem at the moment is thinking of a list that non-committers can subscribe to that would be appropriate for this conversation. license@ is closed, community@ is closed board@ is closed, pmc@ is closed. Where exactly is the best place for these conversations to take place in a manner that is open to contributions from everyone? Regards, Adrian Sutton. === Kangaroo Point MarchFest is an annual festival of music, art, food and culture, that aims to build community spirit and bring all types of people together for a time of fun and entertainment. Sat March 20th, midday till 10pm, at Kangaroo Point Uniting Church. http://www.soulpurpose.com.au/marchfest === - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags
The tags clearly are not ownership oriented. That is why they have dates and what was done. At 01:29 AM 3/11/2004, you wrote: That's exactly the problem: not necessarily who edited the file last, but the owner There are people who see a chance to contribute an enhancement or bug fix. We'd like to have them listed as someone who contributed, but *without* the responsibility of being the owner of the code. cheers, Roland Chris Lamprecht [EMAIL PROTECTED] 11.03.2004 09:54 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc: Subject:Re: @author tags I'm currently reading _The Pragmatic Programmer_, and I just came across the following in a section entitled Comments in Code on page 250: One of the most important pieces of information that should appear in the source file is the author's name -- not necessarily who edited the file last, but the owner. Attaching responsibility and accountability to source code does wonders in keeping people honest ... - 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: @author tags
Can someone tell me in a word or two WHY this change is important? What is the problem that needs to be fixed? At 07:03 AM 3/11/2004, you wrote: Very nice quote. But the owner of HttpClient (and all jakarta project code) is *very* clear. The owner is the Apache Software Foundation (ASF). The individual contributor has contributed the code, and does need to be recognized, but when a commit is made that code no longer belongs to them. It belongs to the ASF. So to follow the Pragmatic Programmer, only the ASF should be listed as the owner, which makes @author tags useless, and confusing from a legal perspective. The copyright statement at the top of every source file attributes ownership to the ASF. Removal of the @author tags is supposed to help protect those listed as @authors legal entanglements, and to empower the PMC. Removing the @author tags does make sense. The only thing that I am disappointed about is that there has been no suitable replacement recognition mechanism agreed upon. But its still being disucssed by the PMC. -jsd Roland Weber wrote: That's exactly the problem: not necessarily who edited the file last, but the owner There are people who see a chance to contribute an enhancement or bug fix. We'd like to have them listed as someone who contributed, but *without* the responsibility of being the owner of the code. cheers, Roland Chris Lamprecht [EMAIL PROTECTED] 11.03.2004 09:54 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc:Subject:Re: @author tags I'm currently reading _The Pragmatic Programmer_, and I just came across the following in a section entitled Comments in Code on page 250: One of the most important pieces of information that should appear in the source file is the author's name -- not necessarily who edited the file last, but the owner. Attaching responsibility and accountability to source code does wonders in keeping people honest ... - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags
Bravo, author of code and especially code parts does not mean owner in any sense. Author means author, which is accurate. At 09:07 AM 3/11/2004, you wrote: I think that owner is intended in the sense of the primary person responsible for maintaining, not in the sense of the legel owner. The programmer is only very rarely the legal owner of his work. Jeff Dever wrote: Very nice quote. But the owner of HttpClient (and all jakarta project code) is *very* clear. The owner is the Apache Software Foundation (ASF). The individual contributor has contributed the code, and does need to be recognized, but when a commit is made that code no longer belongs to them. It belongs to the ASF. So to follow the Pragmatic Programmer, only the ASF should be listed as the owner, which makes @author tags useless, and confusing from a legal perspective. The copyright statement at the top of every source file attributes ownership to the ASF. Removal of the @author tags is supposed to help protect those listed as @authors legal entanglements, and to empower the PMC. Removing the @author tags does make sense. The only thing that I am disappointed about is that there has been no suitable replacement recognition mechanism agreed upon. But its still being disucssed by the PMC. -jsd Roland Weber wrote: That's exactly the problem: not necessarily who edited the file last, but the owner There are people who see a chance to contribute an enhancement or bug fix. We'd like to have them listed as someone who contributed, but *without* the responsibility of being the owner of the code. cheers, Roland Chris Lamprecht [EMAIL PROTECTED] 11.03.2004 09:54 Please respond to Commons HttpClient Project To: Commons HttpClient Project [EMAIL PROTECTED] cc:Subject:Re: @author tags I'm currently reading _The Pragmatic Programmer_, and I just came across the following in a section entitled Comments in Code on page 250: One of the most important pieces of information that should appear in the source file is the author's name -- not necessarily who edited the file last, but the owner. Attaching responsibility and accountability to source code does wonders in keeping people honest ... - 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] - 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: @author tags
On the first issue, I am a lawyer and I can assure you that this worry is, frankly, silly. Unless you are going to hide who did coding, then this is also completely ineffective to meet that worry, which, as I said, is silly anyway. The second issue cannot be commented on because what the social issues are is not stated. Presumably it has something to do with who really did the work or something. That should not be an issue if the tag is used properly. I cannot see, again, how changing how credit is appropriated and documented would change any social issues. Are there any real cases that have actually been at issue that could shed any light on this seemingly unnecessary change in the use of the @author tag? This response has made me think more than ever that this is really a totally unnecessary action which will create a problem and solves none. At 10:04 AM 3/11/2004, you wrote: I'm not on the board, but I'm aware of two issues: 1) The ASF board has concerns over the legal ramifications of @author tags in code. IE it might be possible for someone to sue someone listed as an @author. 2) The tags have caused social issues in some projects (conflicts between people) which has not happened on HttpClient. -jsd Michael McGrady wrote: Can someone tell me in a word or two WHY this change is important? What is the problem that needs to be fixed? - 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: @author tags
I personally think that this is a much more important mistake than people may realize. I would counsel you to go slowly on this one. This one may bite you on the butt. At 11:02 PM 3/9/2004, you wrote: I personally regret this decision. I feel the author tag may be pretty much the only motivating factor for casual contributions. But I will not object Oleg On Wed, 2004-03-10 at 04:32, Michael Becke wrote: The ASF has recently recommended that we discontinue use of @author tags. When first starting out I always enjoyed seeing my name in lights, though I do agree with the ASF's opinion on this matter. If we come to a consensus to remove @authors I suggest that we remove them from all existing code, as well as leave them out of new additions. Any comments? Mike Begin forwarded message: ASF Board Summary for February 18, 2004 snip - author tags are officially discouraged. these create difficulties in establishing the proper ownership and the protection of our committers. there are other social issues dealing with collaborative development, but the Board is concerned about the legal ramifications around the use of author tags - it is quite acceptable and encouraged to recognize developers' efforts in a CHANGES file, or some other descriptive file which is associated with the overall PMC or release rather than individual files. snip - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags
My understanding of human psychology leads me to think that whomever came up with this idea has underestimated the importance of the @author tags to the open source community. At 09:49 AM 3/10/2004, you wrote: Michael, are you saying that removing @author tags would be a mistake? What in particular worries you? In what way do you think it would bite us on the butt? Mike Michael McGrady wrote: I personally think that this is a much more important mistake than people may realize. I would counsel you to go slowly on this one. This one may bite you on the butt. At 11:02 PM 3/9/2004, you wrote: I personally regret this decision. I feel the author tag may be pretty much the only motivating factor for casual contributions. But I will not object Oleg On Wed, 2004-03-10 at 04:32, Michael Becke wrote: The ASF has recently recommended that we discontinue use of @author tags. When first starting out I always enjoyed seeing my name in lights, though I do agree with the ASF's opinion on this matter. If we come to a consensus to remove @authors I suggest that we remove them from all existing code, as well as leave them out of new additions. Any comments? Mike Begin forwarded message: ASF Board Summary for February 18, 2004 snip - author tags are officially discouraged. these create difficulties in establishing the proper ownership and the protection of our committers. there are other social issues dealing with collaborative development, but the Board is concerned about the legal ramifications around the use of author tags - it is quite acceptable and encouraged to recognize developers' efforts in a CHANGES file, or some other descriptive file which is associated with the overall PMC or release rather than individual files. snip - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
