Aux environs du 16/06/04 à 18:49 -0700, sous le titre "Re: [PATCH]
remove deprecated call in WebServer.java", Daniel Rall prit sa plus
belle plume pour écrire les mots suivants:
Thanks, committed in CVS rev 1.26.
Daniel, while you're at it, would you mind committing my 1 year old
patch about a r
On 17 Jun 2004, at 08:02, Jochen Wiedmann wrote:
Hi,
the DateFormat used in the DateTool is supporting only a subset of ISO
8601 date/times. In particular time zones are missing, likewise one
must
not use milliseconds.
The XML-RPC spec (http://www.xml-rpc.com/spec see the last but one
bullet poi
On Do, 2004-06-17 at 09:36, John Wilson wrote:
> The XML-RPC spec (http://www.xml-rpc.com/spec see the last but one
> bullet point) says that timezones may not be present in a date. The
> generally accepted interpretation of the spec is that only the precise
> subset of ISO 8601 date/times give
On 17 Jun 2004, at 09:20, Jochen Wiedmann wrote:
On Do, 2004-06-17 at 09:36, John Wilson wrote:
The XML-RPC spec (http://www.xml-rpc.com/spec see the last but one
bullet point) says that timezones may not be present in a date. The
generally accepted interpretation of the spec is that only the preci
On Do, 2004-06-17 at 10:24, John Wilson wrote:
> The example in the spec does not include milliseconds - the generally
> accepted interpretation of the spec (i.e. by XML-RPC implementers) is
> that they are not permitted.
If so, that leaves still more room for vendor extensions ... :-)
On 17 Jun 2004, at 09:40, Jochen Wiedmann wrote:
On Do, 2004-06-17 at 10:24, John Wilson wrote:
The example in the spec does not include milliseconds - the generally
accepted interpretation of the spec (i.e. by XML-RPC implementers) is
that they are not permitted.
If so, that leaves still more roo
On Do, 2004-06-17 at 10:46, John Wilson wrote:
> The strengths of XML-RPC are its simplicity and interoperability with a
> very wide range of other implementations. The creator of the spec and
> the person who claims ownership of the XMl-RPC trademark has repeatedly
> and vociferously stated th
Hi folks,
About 3 weeks ago I posted about a problem with Apache XML-RPC encoding
Doubles using scientific notation, which does not conform to the spec,
but I didn't see any response.
I don't want to keep pestering you if I'm in the wrong place. Can you
let me know where I should be reporting this
Apache XML-RPC (or at least Helma XML-RPC which became Apache) used to
implement . It was removed at the request of the author of the
spec (Dave Winer). I do not believe that this should be reintroduced.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
On Do, 2004-06-17 at 11:59, John Wilson wrote:
> Apache XML-RPC (or at least Helma XML-RPC which became Apache) used to
> implement . It was removed at the request of the author of the
> spec (Dave Winer). I do not believe that this should be reintroduced.
If so, how do you explain
http://
On 17 Jun 2004, at 11:20, Jochen Wiedmann wrote:
On Do, 2004-06-17 at 11:59, John Wilson wrote:
Apache XML-RPC (or at least Helma XML-RPC which became Apache) used to
implement . It was removed at the request of the author of the
spec (Dave Winer). I do not believe that this should be reintroduced.
On Do, 2004-06-17 at 12:35, John Wilson wrote:
> "MinML-RPC is a minimal XML-RPC implementation. This is very
> interesting, but I have some pushback. There is no such thing as "the
> extension." If we added it, it would break at least one
> implementation. Please appreciate the bigger picture
I'm using ant to build everything. As for the .class files in the
examples/echo directory, I created them using javac, because I didn't see
where they were built through the build system.
Ryan
On Wed, 16 Jun 2004, Daniel Rall wrote:
> Ryan Bloom wrote:
> > I am getting a couple of files in m
On 17 Jun 2004, at 12:00, Jochen Wiedmann wrote:
On Do, 2004-06-17 at 12:35, John Wilson wrote:
"MinML-RPC is a minimal XML-RPC implementation. This is very
interesting, but I have some pushback. There is no such thing as "the
extension." If we added it, it would break at least one
implementation.
At 1:00 PM +0200 6/17/04, Jochen Wiedmann wrote:
However, I still see a difference between an extension, which is *very*
clearly declared as violating the SPEC and turned on the users behalf
only and the addition of a "nil" element without further notice.
In my post yesterday, I was not referring t
On Do, 2004-06-17 at 16:41, John Wilson wrote:
> Others would disagree - Sun's reaction to Microsoft's Java extensions
> would be a good example.
No, it isn't. When using Visual J++ or whatever it was called, you've
never been aware when leaving the standard.
> Vendor specific extensions is an
On Do, 2004-06-17 at 21:37, Steve Quint wrote:
> In my post yesterday, I was not referring to null values as in
> "" or "", but rather to values such as "", and
> "". Should these values be considered valid?
is definitely invalid. Keep in mind, that is equivalent to
. In other words, this wo
17 matches
Mail list logo
