Possible bug in Frontier XML-RPC

18 views
Skip to first unread message

Dave Winer

unread,
May 22, 2018, 12:34:14 PM5/22/18
to frontier-user
I'm putting together a simple XML-RPC client for JavaScript and testing it against a Frontier server.

I hit what looks like a bug in the Frontier implementation, believe it or not. 

I have a simple handler that returns a date value.

on simpleHandler () {
return (clock.now ());

This is what I get back.

<?xml version="1.0"?>
<methodResponse>
<params>
<param>
<value><dateTime.iso8601>20180522T12:04:29</dateTime.iso8601></value>
</param>
</params>
</methodResponse>

The value doesn't appear to conform to the iso 8601 format, and JavaScript's Date.parse () routine doesn't like it.

I would think that the kernel would use date.dateToIso8601String to return the value, but it gets the formatting right.

date.dateToIso8601String (clock.now ())
   «"2018-05-22T12:30:44-04:00"

It's not a big deal, because I can easily work around it. But perhaps something broke somewhere along the line?

Dave



Jake Savin

unread,
May 22, 2018, 9:48:21 PM5/22/18
to fronti...@googlegroups.com, Dave Winer
Hi Dave.

tl;dr: This is most likely a kernel-level bug either in system.verbs.builtins.xml.valToString, or in system.verbs.builtins.xml.coercions.frontierValueToTaggedText, and I don't know of an easy fix without working around the bug on the receiving end.

It looks like I wrote date.dateToIso8601String in 2003, which according to the examples on the W3C site seems to do the right thing: https://www.w3.org/TR/NOTE-datetime

Apparently betty.rpc.server doesn't use it, as it serializes to XML via xml.coercions.frontierValueToTaggedText which was originally implemented in script and then "kernelized" in 1999. The script version called through to xml.valToString to get the ISO-8601 version (in the case of a date), and presumably the kernelized version calls the kernel version of valToString also.

Not sure if this helps at all :-\

Cheers,
-Jake

May 22, 2018 at 9:34 AM
--
You received this message because you are subscribed to the Google Groups "frontier-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to frontier-use...@googlegroups.com.
Visit this group at https://groups.google.com/group/frontier-user.
For more options, visit https://groups.google.com/d/optout.

Dave Winer

unread,
May 23, 2018, 10:09:43 AM5/23/18
to frontier-user


BTW, according to the Wikipedia page on this format --


The form used by Frontier described above is valid. 

Dave


 




Dave Winer

unread,
May 23, 2018, 10:23:14 AM5/23/18
to frontier-user

Now that I know that what Frontier is returning is correct, I was able to add a workaround in my JS code.

function parseDate (theString) {
var theDate = Date.parse (theString);
if (isNaN (theDate)) {
var datePart = stringNthField (theString, "T", 1);
var timePart = stringNthField (theString, "T", 2);
var year = stringMid (datePart, 1, 4);
var month = stringMid (datePart, 5, 2);
var day = stringMid (datePart, 7, 2);
theString = year + "-" + month + "-" + day + "T" + timePart;
theDate = Date.parse (theString);
}
return (theDate);
}

So to the extent that this is an issue, it's closed. ;-)

Dave
Reply all
Reply to author
Forward
0 new messages