Re: [discuss] Slide + HttpComponents = TLP
On Sat, 2007-08-18 at 09:25 +0200, Roland Weber wrote: Oleg Kalnichevski wrote: Could you live with HttpComponents being the name of the new TLP? I would really like to avoid having to come up with a completely new name for the project. HttpComponents use the package org.apache.http. I would prefer something abstract as the home for non-HTTP code such as WebDAV or multipart. How do we do that without a project name to use as the package name? (org.apache.httpcomponents is not an improvement over org.apache.http ;-) What's wrong with org.apache.slide for WebDAV components? Oleg cheers, Roland - 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: [discuss] Slide + HttpComponents = TLP
Oleg Kalnichevski wrote:
What's wrong with org.apache.slide for WebDAV components?
If we're not taking over the full Slide codebase,
and if Slide\{WebDAV-client} is not officially
declared dormant in Jakarta, then we'd have two
independent projects using the same namespace.
Since a WebDAV client based on the 4.0 HttpClient
will be incompatible, it's also a question whether
the same package names should be used. That will
create name clashes in applications that for some
reason - for example during migration - have to
use both old and new packages.
While Martin mentioned in the June board report [1]
that he would like to keep the Slide codebase in
one piece, the current state of the discussion tends
towards carving out the WebDAV client only. In that
case, I wonder whether we should position the new
component as a successor to Slide at all.
cheers,
Roland
[1] http://wiki.apache.org/jakarta/JakartaBoardReport-June2007
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Slide + HttpComponents = TLP
On Sat, 2007-08-18 at 11:49 +0200, Roland Weber wrote:
Oleg Kalnichevski wrote:
What's wrong with org.apache.slide for WebDAV components?
If we're not taking over the full Slide codebase,
and if Slide\{WebDAV-client} is not officially
declared dormant in Jakarta, then we'd have two
independent projects using the same namespace.
Since a WebDAV client based on the 4.0 HttpClient
will be incompatible, it's also a question whether
the same package names should be used. That will
create name clashes in applications that for some
reason - for example during migration - have to
use both old and new packages.
While Martin mentioned in the June board report [1]
that he would like to keep the Slide codebase in
one piece, the current state of the discussion tends
towards carving out the WebDAV client only. In that
case, I wonder whether we should position the new
component as a successor to Slide at all.
If there are no plans to develop non-client bits any further, I
personally think WebDAV client should keep Slide as its name. Slide is a
well established brand and I see no benefit in discarding it and coming
up with some new fancy name.
Oleg
cheers,
Roland
[1] http://wiki.apache.org/jakarta/JakartaBoardReport-June2007
-
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: [discuss] Slide + HttpComponents = TLP
Oleg Kalnichevski wrote: If there are no plans to develop non-client bits any further, That exactly is my concern. I still hope for some more input from Slide developers. I personally think WebDAV client should keep Slide as its name. I could live with that. Slide is a well established brand As a server component that happens to have a little client-side WebDAV library as an add-on. and I see no benefit in discarding it Disassociation from the server side. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Slide + HttpComponents = TLP
On Sat, 2007-08-18 at 12:21 +0200, Roland Weber wrote: Oleg Kalnichevski wrote: If there are no plans to develop non-client bits any further, That exactly is my concern. I still hope for some more input from Slide developers. I personally think WebDAV client should keep Slide as its name. I could live with that. Slide is a well established brand As a server component that happens to have a little client-side WebDAV library as an add-on. and I see no benefit in discarding it Disassociation from the server side. What is the benefit of that? At any rate in my opinion it is not worth trouble of rebranding the whole project. Oleg cheers, Roland - 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: [discuss] Slide + HttpComponents = TLP
Disassociation from the server side. What is the benefit of that? At any rate in my opinion it is not worth trouble of rebranding the whole project. Will the current [EMAIL PROTECTED] and [EMAIL PROTECTED] mailing lists continue to exist alongside [EMAIL PROTECTED] and [EMAIL PROTECTED], where the Slide WebDAV client finds a new home? That would be bound to confuse users. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r567258 - in /jakarta/site: docs/ docs/site/ docs/site/downloads/ docs/site/news/ docs/site/pmc/ xdocs/stylesheets/
On 18/08/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: tetsuya Date: Sat Aug 18 04:14:52 2007 New Revision: 567258 URL: http://svn.apache.org/viewvc?view=revrev=567258 Log: Apache DB (http://db.apache.org/), especially OJB and Torque had been in Jakarta - Ex-Jakarta. - Now I am using CHCP 1252 mode (for ISO-8859-1 characters) Is there a way to fix build.xml so that the user's default encoding does not affect the output? Or perhaps we could add a check and warn if the encoding is wrong? The xml source files are already flagged as ISO-8859-1, as is the stylesheet, which uses output encoding ISO-8859-1 as well, which one might have hoped would be enough... As an alternative, I tried to generate the output to use ouml;/uuml; etc instead of the iso-8859-1 characters, but could not work out how to code this in the source XML without generating errors. It might solve the problem if the XSLT output format were changed from xml to html, but I assume there are good reasons for using xml as the output format, and it would mean updating every page. S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Slide + HttpComponents = TLP
On Sat, 2007-08-18 at 13:40 +0200, Roland Weber wrote: Disassociation from the server side. What is the benefit of that? At any rate in my opinion it is not worth trouble of rebranding the whole project. Will the current [EMAIL PROTECTED] and [EMAIL PROTECTED] mailing lists continue to exist alongside [EMAIL PROTECTED] and [EMAIL PROTECTED], where the Slide WebDAV client finds a new home? Yes, as aliases. I think it is a standard practice. But it is a detail when can take care of in the normal course of things. Oleg That would be bound to confuse users. cheers, Roland - 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: svn commit: r567258 - in /jakarta/site: docs/ docs/site/ docs/site/downloads/ docs/site/news/ docs/site/pmc/ xdocs/stylesheets/
sebb wrote: Is there a way to fix build.xml so that the user's default encoding does not affect the output? Or perhaps we could add a check and warn if the encoding is wrong? The xml source files are already flagged as ISO-8859-1, as is the stylesheet, which uses output encoding ISO-8859-1 as well, which one might have hoped would be enough... I don't know what the exact symptoms of the problem are. This is what the XSLT spec says about output encodings [1]: The encoding attribute specifies the preferred encoding to use for outputting the result tree. XSLT processors are required to respect values of UTF-8 and UTF-16. For other values, if the XSLT processor does not support the specified encoding it may signal an error; if it does not signal an error it should use UTF-8 or UTF-16 instead. Is the output generated in UTF-8 or UTF-16? Then the solution would be to use one of those as the output encoding, since only those are required to be supported on all platforms. cheers, Roland [1] http://www.w3.org/TR/xslt#section-XML-Output-Method - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
