Re: [codec] RE: more common classes need a home
On Tue, 4 Feb 2003, Incze Lajos wrote: In message [EMAIL PROTECTED], Hen ri Yandell writes: I'm +1 to commons-uri. What about commons-naming? That's JNDI. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
Sung-Gu wrote: I don't think it's not mature... :( They have couple of issues still, as I know.. just not revealed yet. At least they have reached Alpha status! This is more than enough for a real commons sub-project outside the sandbox. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[codec] RE: more common classes need a home
Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was initially from the HttpClient project. The codec Base64 class has an open bug which also should point us in the right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440 So, I'll make a proposal and hope for lazy consensus: Let's replace Base64 in codec with the current HttpClient version. Tim O'Brien -Original Message- From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 1:04 AM To: Jakarta Commons Developers List Subject: Re: more common classes need a home *commons.codec* sounds like a good place for this class. Perhaps you could look at the various current implementations, and see if you can provide a common Base64 class attractive to everyone in Jakarta. Currently these projects (at least) have one plus your new codec package: tomcat xml-rpc slide httpclient Three cheers for code reuse! This goes into codec, which is still in Sandbox. Infact there's already a Base64 there, but I'm not sure how well it matches Slide's needs. - 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: [codec] RE: more common classes need a home
+1 Any timeline for raising codec out of the sandbox? O'brien, Tim wrote: Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was initially from the HttpClient project. The codec Base64 class has an open bug which also should point us in the right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440 So, I'll make a proposal and hope for lazy consensus: Let's replace Base64 in codec with the current HttpClient version. Tim O'Brien -Original Message- From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 1:04 AM To: Jakarta Commons Developers List Subject: Re: more common classes need a home *commons.codec* sounds like a good place for this class. Perhaps you could look at the various current implementations, and see if you can provide a common Base64 class attractive to everyone in Jakarta. Currently these projects (at least) have one plus your new codec package: tomcat xml-rpc slide httpclient Three cheers for code reuse! This goes into codec, which is still in Sandbox. Infact there's already a Base64 there, but I'm not sure how well it matches Slide's needs. - 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: [codec] RE: more common classes need a home
It might need a little time for Tim to get things sorted out. It's all a bit messy in there. I guess the question needs to be whether it should focus on new functionalities or wrapping up enough to goto Commons-proper. Hen On Mon, 3 Feb 2003, Jeffrey Dever wrote: +1 Any timeline for raising codec out of the sandbox? O'brien, Tim wrote: Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was initially from the HttpClient project. The codec Base64 class has an open bug which also should point us in the right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440 So, I'll make a proposal and hope for lazy consensus: Let's replace Base64 in codec with the current HttpClient version. Tim O'Brien -Original Message- From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 1:04 AM To: Jakarta Commons Developers List Subject: Re: more common classes need a home *commons.codec* sounds like a good place for this class. Perhaps you could look at the various current implementations, and see if you can provide a common Base64 class attractive to everyone in Jakarta. Currently these projects (at least) have one plus your new codec package: tomcat xml-rpc slide httpclient Three cheers for code reuse! This goes into codec, which is still in Sandbox. Infact there's already a Base64 there, but I'm not sure how well it matches Slide's needs. - 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: [codec] RE: more common classes need a home
+1 Maybe chunked transfer encoding and URL encoding would fit into this package as well somehow? Odi O'brien, Tim wrote: Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was initially from the HttpClient project. The codec Base64 class has an open bug which also should point us in the right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440 So, I'll make a proposal and hope for lazy consensus: Let's replace Base64 in codec with the current HttpClient version. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] RE: more common classes need a home
URI, URL, and URNs are very general - and used everywhere in ASF - this sounds like prime content for the Apache Commons. I don't think that [codec] is the appropriate place for UR[LIN] code, but maybe chunked transfer encoding. I think this is even more general than networks, go to the ISOC, IANA, IAB, ITU, INTA, WIPO archives: http://www.faqs.org/rfcs/index.html, and you'll probably find that URLs are used for more things than you could've imagined. Specifically, I've been taking a crack at telephony, and you've got SIP urls and TEL urls, etc... Tim O'Brien -Original Message- From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 11:37 AM To: Jakarta Commons Developers List Subject: Re: [codec] RE: more common classes need a home Maybe chunked transfer encoding and URL encoding would fit into this package as well somehow? Both of those are very http specific. I'm trying to find a home for all the URI, URIUtil, HttpURL ... classes too, but don't think that should be codec. There were some suggestions like commons-net, but its taken. Perhaps there is enough code for their own package commons-uri. http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] ache.orgmsgNo=23684 - 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: [codec] RE: more common classes need a home
I'm +1 to commons-uri. As Tim points out, it's not just URLs, so we could even have pieces of code for dealing with ISBNs etc if the need arose. I don't think they really tie well to commons-io, and losing them in commons-net would be a mistake probably. Hen On Mon, 3 Feb 2003, O'brien, Tim wrote: URI, URL, and URNs are very general - and used everywhere in ASF - this sounds like prime content for the Apache Commons. I don't think that [codec] is the appropriate place for UR[LIN] code, but maybe chunked transfer encoding. I think this is even more general than networks, go to the ISOC, IANA, IAB, ITU, INTA, WIPO archives: http://www.faqs.org/rfcs/index.html, and you'll probably find that URLs are used for more things than you could've imagined. Specifically, I've been taking a crack at telephony, and you've got SIP urls and TEL urls, etc... Tim O'Brien -Original Message- From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 11:37 AM To: Jakarta Commons Developers List Subject: Re: [codec] RE: more common classes need a home Maybe chunked transfer encoding and URL encoding would fit into this package as well somehow? Both of those are very http specific. I'm trying to find a home for all the URI, URIUtil, HttpURL ... classes too, but don't think that should be codec. There were some suggestions like commons-net, but its taken. Perhaps there is enough code for their own package commons-uri. http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] ache.orgmsgNo=23684 - 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: [codec] RE: more common classes need a home
On Mon, Feb 03, 2003 at 10:46:23AM -0600, O'brien, Tim wrote: Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was initially from the HttpClient project. The codec Base64 class has an open bug which also should point us in the right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440 So, I'll make a proposal and hope for lazy consensus: Let's replace Base64 in codec with the current HttpClient version. I believe that was actually Scott Sanders (sanders), not Sander Striker (striker) :) -- Scott Sanders - [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] RE: more common classes need a home
My apologies, Scott, my apologies. Tim O'Brien -Original Message- From: Scott Sanders [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 11:58 AM To: Jakarta Commons Developers List Subject: Re: [codec] RE: more common classes need a home On Mon, Feb 03, 2003 at 10:46:23AM -0600, O'brien, Tim wrote: Rev 1.1 of Base64 was checked in by Sander Striker about 1 year ago. It was initially from the HttpClient project. The codec Base64 class has an open bug which also should point us in the right direction: http://issues.apache.org/bugzilla/show_bug.cgi?id=16440 So, I'll make a proposal and hope for lazy consensus: Let's replace Base64 in codec with the current HttpClient version. I believe that was actually Scott Sanders (sanders), not Sander Striker (striker) :) -- Scott Sanders - [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: [codec] RE: more common classes need a home
I tried to read to the end of the thread so far before replying. If the feeling is that the classes will see more use distributed separately from HttpClient, I concur with Henri's assessment below. In message [EMAIL PROTECTED], Hen ri Yandell writes: I'm +1 to commons-uri. As Tim points out, it's not just URLs, so we could even have pieces of code for dealing with ISBNs etc if the need arose. I don't think they really tie well to commons-io, and losing them in commons-net would be a mistake probably. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
I think, as I see, 'Jakarta commons' indicates the square of applications for the small fuctions usefule to be used by other projects or applications. It means there aren't any way to refer to some or several reusable classes in an easiness. BTW, jsd is asking to refer and use some classes, I guess. Any suggestions? Since the commons package has not been for only re-usable classes, (but small apps) I think it's better for me to start a new sandbox using URI and related classes. If it were going on, it would be an experimetal web client based on a new archicture. Sung-Gu - Original Message - From: Tomasz Pik [EMAIL PROTECTED] Subject: Re: more common classes need a home Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java Base64 into 'codec' but the rest? commons-net is reserved... in the time of moving from 'sandbox'. Maybe it's a good moment for change from commons-net to commons-protocols? Or maybe those classes should go into commons-lang (another subpackage, lang.net, another long discussion about the scope of lang :-)? -- Regards Tomek Pik Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
The re-use structure is completely package based. So smaller packages are more re-usable. I think a commons.uri package with those 6 or 8 files is a nice, small, focused, re-usable package. These classes are quite mature and so do not need to be in the sandbox: they should be allowed to go right into commons proper. I'm willing to help out with the administrative aspect of setting up a commons-uri project including project proposal, releases, stuff like that. Any experimental web client work should be done in the sandbox seperately. Sung-Gu wrote: I think, as I see, 'Jakarta commons' indicates the square of applications for the small fuctions usefule to be used by other projects or applications. It means there aren't any way to refer to some or several reusable classes in an easiness. BTW, jsd is asking to refer and use some classes, I guess. Any suggestions? Since the commons package has not been for only re-usable classes, (but small apps) I think it's better for me to start a new sandbox using URI and related classes. If it were going on, it would be an experimetal web client based on a new archicture. Sung-Gu - Original Message - From: Tomasz Pik [EMAIL PROTECTED] Subject: Re: more common classes need a home Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java Base64 into 'codec' but the rest? commons-net is reserved... in the time of moving from 'sandbox'. Maybe it's a good moment for change from commons-net to commons-protocols? Or maybe those classes should go into commons-lang (another subpackage, lang.net, another long discussion about the scope of lang :-)? -- Regards Tomek Pik Jandalf. - 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]
more common classes need a home
There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java First of all, I think these should come out of Slide as part of their migration to commons-httpclient which is still underway. Second, I thnk that these classes are too general to be part of HttpClient. They have use well beyond a http client, and so should be available to other packages without requiring the commons-httpclient.jar. Do people agree with me? If so, any idea where these could go? Perhaps the root of org.apache.commons? or a new commons-net package? put Base64 in commons-lang, and create a new commons-uri package? If we do this, would it be better for HttpClient to roll the classes into the commons-httpclient.jar, or require it as a dependancy? Any comments would be helpful. Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: more common classes need a home
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]] put Base64 in commons-lang, This goes into codec, which is still in Sandbox. Infact there's already a Base64 there, but I'm not sure how well it matches Slide's needs. NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
*commons.codec* sounds like a good place for this class. Perhaps you could look at the various current implementations, and see if you can provide a common Base64 class attractive to everyone in Jakarta. Currently these projects (at least) have one plus your new codec package: tomcat xml-rpc slide httpclient Three cheers for code reuse! This goes into codec, which is still in Sandbox. Infact there's already a Base64 there, but I'm not sure how well it matches Slide's needs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java Base64 into 'codec' but the rest? commons-net is reserved... in the time of moving from 'sandbox'. Maybe it's a good moment for change from commons-net to commons-protocols? Or maybe those classes should go into commons-lang (another subpackage, lang.net, another long discussion about the scope of lang :-)? -- Regards Tomek Pik Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] name clash? (Was: more common classes need a home)
On Mon, 3 Feb 2003, Tomasz Pik wrote: Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java Base64 into 'codec' but the rest? commons-net is reserved... in the time of moving from 'sandbox'. Maybe it's a good moment for change from commons-net to commons-protocols? Or maybe those classes should go into commons-lang (another subpackage, lang.net, another long discussion about the scope of lang :-)? Definitely outside commons-lang scope I think. I'd have said 'commons-net' too, but there is already a project there. Any ideas from the [net] people? :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java First of all, I think these should come out of Slide as part of their migration to commons-httpclient which is still underway. Second, I thnk that these classes are too general to be part of HttpClient. They have use well beyond a http client, and so should be available to other packages without requiring the commons-httpclient.jar. Do people agree with me? If so, any idea where these could go? Perhaps the root of org.apache.commons? or a new commons-net package? put Base64 in commons-lang, and create a new commons-uri package? Base64 at least is in the Commons Codec package, which is currently in the sandbox. In Apache XML-RPC, we recently discovered interoperability problems with Base64, and fixed them. We will be pushing these changes upstream to Codec. We are leaning towards introducing a dependency instead of rolling them into our JARs, as some of the contributors have found wierd classloader problems if the same class is in the classpath more than once. I would agree with you for the others, they are useful to more than just this project. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
Jeffrey Dever wrote: Also noticed that codec and xml-rpc also have their own Base64 classes. You can also add Tomcat to the list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
Sounds like Base64 has found a home. What are HttpsURL and HttpURL generally used for? The various URI classes seem to need a home. They might be big enough for their own package. Where is URLUtil? We should probably require the various classes as a dependency. The only down side being that a person has to download a lot more jars, etc. to get started working with HttpClient. It's kind of nice to have everything in one jar. Perhaps that could be a release option. We could package everything in one jar as a fat release and have just HttpClient code as another skinny option. Mike On Sunday, February 2, 2003, at 07:17 PM, Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java First of all, I think these should come out of Slide as part of their migration to commons-httpclient which is still underway. Second, I thnk that these classes are too general to be part of HttpClient. They have use well beyond a http client, and so should be available to other packages without requiring the commons-httpclient.jar. Do people agree with me? If so, any idea where these could go? Perhaps the root of org.apache.commons? or a new commons-net package? put Base64 in commons-lang, and create a new commons-uri package? If we do this, would it be better for HttpClient to roll the classes into the commons-httpclient.jar, or require it as a dependancy? Any comments would be helpful. Jandalf. - 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]
more common classes need a home
There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java First of all, I think these should come out of Slide as part of their migration to commons-httpclient which is still underway. Second, I thnk that these classes are too general to be part of HttpClient. They have use well beyond a http client, and so should be available to other packages without requiring the commons-httpclient.jar. Do people agree with me? If so, any idea where these could go? Perhaps the root of org.apache.commons? or a new commons-net package? put Base64 in commons-lang, and create a new commons-uri package? If we do this, would it be better for HttpClient to roll the classes into the commons-httpclient.jar, or require it as a dependancy? Any comments would be helpful. Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
What are HttpsURL and HttpURL generally used for? Nothing. They are never even imported in httpclient classes, they are just ghosts in some comments and log strings. Thats part of the reason why I want to move them away from here. Also I don't find them a particularly useful abstraction that justifies an inheritence hierachy. The various URI classes seem to need a home. They might be big enough for their own package. org.apache.jakarta.commons.uri Sounds like a good candidate to me. Sung-Gu appears to be the only one who works on these (same story in the Slide project) so it would be good to hear what he has to say. Where is URLUtil? Dunno. Seems logical though. We should probably require the various classes as a dependency. The only down side being that a person has to download a lot more jars, etc. to get started working with HttpClient. It's kind of nice to have everything in one jar. Perhaps that could be a release option. We could package everything in one jar as a fat release and have just HttpClient code as another skinny option. We still have this problem now, as commons-logging is required to build or run httpclient. This is where I look to Commons to provide some guidance on this as its a general project problem. Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] name clash? (Was: more common classes need a home)
On Mon, 3 Feb 2003, Tomasz Pik wrote: Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java Base64 into 'codec' but the rest? commons-net is reserved... in the time of moving from 'sandbox'. Maybe it's a good moment for change from commons-net to commons-protocols? Or maybe those classes should go into commons-lang (another subpackage, lang.net, another long discussion about the scope of lang :-)? Definitely outside commons-lang scope I think. I'd have said 'commons-net' too, but there is already a project there. Any ideas from the [net] people? :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more common classes need a home
Jeffrey Dever wrote: There are still a bunch of classes that are in both HttpClient and Slide. In particular: Base64.java HttpsURL.java HttpURL.java URIException.java URI.java URIUtil.java URLUtil.java Base64 into 'codec' but the rest? commons-net is reserved... in the time of moving from 'sandbox'. Maybe it's a good moment for change from commons-net to commons-protocols? Or maybe those classes should go into commons-lang (another subpackage, lang.net, another long discussion about the scope of lang :-)? -- Regards Tomek Pik Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
