Hi Digg API community,

I'm one of the developers for the dojotoolkit's rpc system and I
wanted to add digg in as one of the available endpoints and write a
little blog about how that was done.  Dojo's rpc system already
provides access to services based on JsonRPC or JsonpServices with
simple description in the form of json, called SMD.   I can and would
like to implement this quickly, but have a question and a feature
request and am wondering what the possibilities of either are :)

1) Can elements that are currently provided as part of the url also be
provided by a querystring parameter? For example, currenly to you
might do  /errors/{code}?appkey=foobar....  I'm wondering if this is
also available as some thing like /errors?
code=1001&appkey=foobar.... .

2) In brief testing, the system is millimeters away from working with
the default config, meaning that only a definition  (no code) would
even need to be written.   The above issue would make that very easy,
but I might be able to work around it if that doesn't work or isn't
going to ever work.  The other item however is currently a blocker as
it depends on other parts of the dojo system i'm not wanting to fiddle
with.  The issue is simply that the callback function name passed to
the api is not accepted by the digg api and instead returns an
'alert('A Digg API request has an invalid callback argument.');'  The
string passed as the callback parameter
'dojo.io.script.jsonp_dojoIoScript1._jsonpCallback'

This function is of course hooked up and managed in the background for
the dojo user so none of the complexity of jsonp style callbacks are
required and also to ensure there is no collision of function names
for callbacks.  These functions are isolated to holder in the
providing packages namespace as appropriate, however the digg api
doesn't seem to like the fact that there are periods in the callback
function name, though they are neither inappropriate or invalid.  I've
also verified that is not the underscores that it doesn't like.  Would
it be possible to relax this restriction on the callback parameter?

Thanks,
Dustin

On Nov 1, 9:18 pm, Dustin <dustin.ma...@gmail.com> wrote:

No. Currently the API only responds to requests in the fashion that is
documented here: http://apidoc.digg.com/. When attempting to use query
string parameters that aren't supported you should receive an
"Unrecognized argument" error.

The Javascript response type decodes the JSON response and passes the
data to a Javascript callback function you specify in the callback
argument in the request. I believe the '.' character is not valid in a
Javascript function name, thus the restriction.

On Nov 2, 12:13 am, k...@digg.com wrote:

This is incorrect, the period certainly is valid.  We will take a look
at relaxing the restriction.

-Kurt

Thanks.

On Nov 2, 3:36 am, k...@digg.com wrote:

At 08:18 PM 11/1/2007, Dustin wrote:

True, the dots are not invalid.  We restricted the callback arg to
just a simple identifier so that we wouldn't have to do any analysis
to prove there's no vulnerability in allowing operators like
dot.  (Micah even suggested we allow square brackets, too, but I got
scared and ran away.)

It's possible, but first let me ask you: Would it be onerous to
assign a reference to the function to a variable and then use that
variable as the callback?

The typical pattern for the type=javascript API call is:

<script>
function blee(jsonData) {
  ...

</script>
<script
src="http://services.digg.com/...?type=javascript&callback=blee..."></script>

In your case, you would calculate the function reference in the first
script tag.

<script>
blee = dojo.io.script.jsonp_dojoIoScript1._jsonpCallback;
</script>

I realize that's less elegant, and that may be enough of an argument,
but how much worse would it be?  Or does it preclude the use of your
library altogether?

I'm not trying to talk you out of it.  I'm sorta trying to talk
myself more completely into the need for dots.

Steve's right, dots can be referenced, but I'm rallying for url-encoded
brackets in the callback.  : )

My problem is that I'm making a variable number of requests to the Digg API
on a page, and it's crucial that the responses be handled in a certain order
by unique functions.

My solution, which I've utilized with the Yahoo API, is to use a JavaScript
array (dynamically generated) as a sort of 'variable' variable to reference
functions.  This allows me to sort of 'tag' responses.  Example:

unique_functions[0] = function (r) { }
unique_functions[1] = function (r) { }
...

So I'm looking to call the Digg API as such:
http://services.digg.com/topics?appkey=http%3A%2F%2Fexample.com&type=...

( 'unique_functions%5B4%5D' is the url-encoded 'unique_functions[4]' )

Unfortunately, that's not possible yet.

I know that allowing url-encoded brackets will require some vulnerability
checking, but if it's any comfort, Yahoo's API specifically allows
url-encoded brackets in the callback:

http://developer.yahoo.com/common/json.html
"Important: brackets requested in callbacks must be URL encoded"

Thanks!

Thanks for the additional data point.  I'll discuss it with our
Javascript guru again, but I can't promise we'll support callbacks
other than simple identifier names.

At 01:53 PM 6/24/2008, Pat Diven II wrote:

I'm curious.  How does the array ensure that the responses are
handled in a certain order?  (Be gentle with me.  I'm no Javascript expert.)

Thanks, Steve!

It's the only way we'll be able to know which response is which among
multiple responses, since our identifier names are dynamic.  If you're
wondering about the application, it's an embeddable bit that others
may initiate more than once on a page, which is why we're using
dynamic identifier names.  We need that callback.  ; )

I used the wrong word.  Order doesn't matter; pairing does.  What's
imperative is that we make sure we pair responses with the correct
functions.

On Jun 24, 6:54 pm, Steve Williams <s...@digg.com> wrote:

At 07:57 PM 6/24/2008, PC wrote:

This sounds really interesting.  Can you give a bit more complete
example?  I'd like to see the Javascript code that sets up the array
in context with the API requests.  Maybe you can point to an example
page that doesn't work because of the constraints on the callback value?

On Jun 24, 6:54 pm, Steve Williams <s...@digg.com> wrote:

That discussion happened, and we've decided to allow member operators
as well as regular identifiers. Good news for everyone, right?

For reference (and this isn't official until you see it in the API
docs, and of course it's still subject to tweaks) we plan to expand
our check to include:

Almost any legal identifier* -
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Variab...
Bracket and dot member operators -
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Op...

*Note: There should eventually be full Unicode support for
identifiers, but I'm not the guy who owns that code so I'll avoid
making promises on the API team's behalf. For now, stick to _$a-Z.

Cheers,
- Micah

Steve, Micah: you both rock!  Thank you.

Steve, I'll see about posting a testcase here sometime after lunch.

On Jun 25, 12:30 pm, mi...@digg.com wrote:

Any idea when this will happen?  Thanks.