*bump*
This needs a solution.
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jord...@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
-Original Message-
From: Jordan Zimmerman [mailto:jord...@shop.com]
Sent: Thursday, April 16, 2009 3:20 PM
I'd throw some setters on BasicHttpFetcher
https://issues.apache.org/jira/browse/SHINDIG-1018
Jordan Zimmerman
Principal Software Architect
831.647.4712
831.214.2990 (cell)
jord...@shop.com
SHOP*COMTM
Shop Smart, Save Big(tm)
www.shop.com
This message (including any attachments) is intended
Chris,
Done.
https://issues.apache.org/jira/browse/SHINDIG-1020
-Mark W.
From:
Chris Chabot chab...@google.com
To:
shindig-dev@incubator.apache.org
Date:
04/17/2009 11:53 AM
Subject:
Re: Another Shindig OAuth example
Hey Mark,
Great news to hear you got it up and running!
From a pure
1) Why does the Shindig Activity object break out all the fields of the
activity as separate getters/setters? It seems redundant with the Field
enum.
2) The specs I've seen state that it is usually beneficial to create
activities using Message Templates. But, I don't see where Message
Templates
Sorry to take so long to review. I was OOO for 2 weeks. This looks good.
I'm happy to commit as is
http://codereview.appspot.com/27104/diff/4001/4015
File
java/gadgets/src/main/java/org/apache/shindig/gadgets/parse/nekohtml/NekoCompactSerializer.java
(right):
1. All the Java POJOs have get/set as the data binders use that rather than
fields
2. A hole in the spec that no one has been clamoring to fix IMHO
On Fri, Apr 17, 2009 at 3:26 PM, Jordan Zimmerman jord...@shop.com wrote:
1) Why does the Shindig Activity object break out all the fields of the
Why is it necessary to make it a class? If we need a few more error
codes, we can add some extra enums.
If there really is a need to support any HTTP error code and this has
to be a class, there should be some assurance that the built-in HTTP
status codes and jsonValues are not reused - this
Why not just use actual HTTP error codes? I'll personally guarantee that
they never change.
On Fri, Apr 17, 2009 at 4:05 PM, Adam Winer awi...@gmail.com wrote:
Why is it necessary to make it a class? If we need a few more error
codes, we can add some extra enums.
If there really is a need
Quick question regarding the recent work with Shindig's OAuth support.
Here's the scenario: I've got two instances of Shindig running, one on
port 7070 the other on 8080. What I'd like to be able to do is a
makeRequest(restURL) from a gadget on 8080 to 7070. This would cause the
OAuth to kick
As per the Json-RPC spec
http://groups.google.com/group/json-rpc/web/json-rpc-1-2-proposal?pli=1#error-object
and
http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/rpc-protocol
(Section
Standard Error)
a server can use error codes from -32099..-32000 for implementation-defined
A client may want to let user know very clear error message why an operation
failed. For example, LIMIT_EXCEEDED defined currently only tells that some
limit was exceeded. If you take the case of photo upload, we are not sure if
it was number of photos in an album, or number of total photos
The content type can (and should) be specified in the request headers.
You probably want something like this:
gadgets.io.makeRequest(localhost:7070/social/api, callback, {
METHOD: POST,
AUTHORIZATION: OAUTH,
CONTENT_TYPE: JSON, // This refers to the expected result type
POST_DATA:
12 matches
Mail list logo
