is there a skeleton java backend (json rpc) for qooxdoo js framework?
Could any json RPC backend work for qooxdoo or we need the date hack to have it work?
Regards,
TL;DR: If you set the "protocol" property to "2.0", you should be able to interoperate with any standards-based JSON-RPC 2.0 server.
Detailed answer:
The qooxdoo JSON RPC client supports both its original protocol, a variation of JSON-RPC 1.0 called "qx1" (the default, for age-old backward compatibility), and the standardized JSON-RPC 2.0. You'll want to switch it to 2.0 by setting the "protocol" property to "2.0". If I recall correctly, our JSON-RPC client is then fully 2.0 standards-compliant except that we don't support batch requests.
Additionally, as you've noted, qooxdoo used to try to fix the "bug" in JSON/JavaScript, that there is no literal form for a Date object as there is for all other types in JavaScript. The qooxdoo JSON-RPC implementation has provisions for automatically converting Date objects into a string format that is easily parsed.
As of many years ago, we realized that it was poor form to muck with JSON-RPC since mucking with it allowed us to communicate only with qooxdoo-enhanced JSON-RPC servers. At that time, we changed the default to not do any date conversions. This is controlled by the static variable, qx.io.remote.Rpc.CONVERT_DATES, which can be set to true to "fix the bug" as we did originally, or left at its now default null (or false) value, which says "do not muck with dates."
That's all a long-winded answer to say that qooxdoo's JSON-RPC client, if you switch it to use the 2.0 protocol, should interoperate fine with any standards-based JSON-RPC 2.0 server.
Derrell
Related
I'm working on a UWP app with a feature where other apps could set Discord Rich Presence via an AppServiceConnection. However on most UWP platforms forwarding from the AppServiceConnection to the Offical Client is not an available option. I'm looking to set the Rich Presence directly from the app essentially. Despite a ton of digging through network packets I'm still entirely lost. Anyone know of documentation on it or has some super method to sniff these packets out (Fiddler 4, Netmon and Wireshark aren't cutting it)
The only possible ways to set a rich presence are documented in the official SDK which uses IPC for setting the presence. sdk on github official documentation
As you can see on github, some people have already written libraries for other languages based on the official SDK: wrappers and implementations.
After a lot more Reverse Engineering, the Rich Presence is sent via the Gateway with op code 3 and the Game object, Minimum args Name and Type and a far more complex object you can find in https://github.com/Avid29/QuarrelRichPresence/blob/master/Objects.cs
I can't seem to find in the Identity Server 4 documentation on how to support Clients that are 3rd party developers and not just applications.
How can I implement a custom IClientStore to support clients that are actually developers connecting to my APIs.
Thanks
The official docs mention this:
At runtime, clients are retrieved via an implementation of the IClientStore. This allows loading them from arbitrary data sources like config files or databases. For this document we will use the in-memory version of the client store. You can wire up the in-memory store in ConfigureServices via the AddInMemoryClients extensions method.
This suggests that you should provide your own implemenation. I'd presume this as well, given this similar (perhaps even duplicate?) question, and that one of the IDS4 authors seems (at first glance) to suggest something similar.
Bottom line: roll your own IClientStore implementation.
I am working on MVC 4 project with AngularJS. I have some date filed in my form. I am facing an strange issue when i post data to server using $http.post(). When i post any date like January 01,2013 is converted to 12/31/2012 on Server which gives an error on Server Post. I am not getting what is going wrong in my code base.
Hope you got my question.
When dealing with dates you have to be careful as to how they are serialised on the front-end and back-end. There is no standard.
Given your description and lack of other context though, I suspect it's a time zone issue.
are you developing locally? i.e. are browser and server running on the same machine?
(if not) what's the timezone the server is using? UTC?
Here's a post detailing some issues with JSON date serialization: "On the nightmare that is JSON Dates. Plus, JSON.NET and ASP.NET Web API"
If you're not sure what's going on with serialisation you can use something like curl (*nix or maybe cygwin tool) or "Fiddler" to see the raw responses. Other things to do are to explicitly use date's toString() method to serialise the date as a string (and change on the server side too seeing you're using .Net) to explicitly control the deserialisation.
We tried last night to build some code which would create a new public folder in Microsoft Exchange from within a .NET Winforms application.
Googling for code took us to a bunch of code samples involving http requests and WebDAV. We experienced all kinds of painfulness involving
The underlying connection was closed: Could not establish trust
relationship for the SSL/TLS secure channel.
and
The remote server returned an error: (440) Login Timeout.
and had to call it a day.
This morning I remembered that we had some old VBA code which used the Outlook Object Model to deal with Exchange Public Folders. Dug it out, adapted it to .NET and, hey, it works. Really it's just a couple of lines.
Is there a reason to use http & WebDAV rather than OOM? Are the WebDAV examples basically for ASP.NET development? If we could have got the WebDAV code to work in our case would it have given us any extra power or flexibility (e.g. in cases where the user has restricted permissions)?
See http://www.infinitec.de/post/2008/11/26/ExchangeWebServices-WebDAV-and-untrusted-server-certificates.aspx for the SSL thingy and http://www.infinitec.de/post/2004/12/31/Access-the-Exchange-store-via-WebDAV-with-Form-Based-Authentication-turned-on-Updated.aspx for the Login-Timout.
If you use the OOM, you rely on Outlook being installed and property configured (which can be somewhat difficult you have multiple profiles).
WebDAV ist a HTTP protocol, meaning that you have very little prerequisites. That being said, WebDAV for Exchange is a rather cumbersome protocol. There are, however .NET wrappers available (I can send you one which is free - just ping me through my website) which makes it easier.
But know that WebDAV for Exchange is only supported in Exchange 2003 and 2007. Since Exchange 2007, WebServices are available and there is even a managed API:
EWS Managed API - Download: http://www.microsoft.com/download/en/details.aspx?id=13480
EWS Managed API - SDK: http://msdn.microsoft.com/en-us/library/dd633710(v=exchg.80).aspx
What technologies are used / recommended for HTTP Rpc Calls from Silverlight. My Server Side stack is JBoss (servlets / json_rpc [jabsorb]), and we have a ton of business logic (object creation, validation, persistence, server side events) in place that I still want to take advantage of.
This is our first attempt at bringing an applet style ria to our product, and ideally we keep both HTML and Silverlight versions.
For better or worse the powers that be have pushed us down the silverlight path, and while flex / java fx / silverlight is an interesting debate, that question is removed from the equation. We just have to find a way to get silverlight to behave with our classes.
Should I be defining .NET Class representation of our JSON objects and the methodology to serialize / deserialize access to those objects? IE "blah.com/dispenseRpc?servlet=xxxx&p1=blah&p2=blahblah creating functions that invoke the web request and convert the incomming response string to objects?
Another way would be to reverse engineer the .NET wcf(or whatever) communications and implement the handler on the Java side that invokes the correct server side code and returns what .NET expects back. But that sounds much trickier.
T
Well since we are using JSON Rpc over HTTP on the server -> HTML clients, we decided to use HTTP calls and the .NET JsonSerializer; future plans are to add Java Annotations on our EJB project and a console applciation that will run against the EJB and generate the HTTP calls and F# Records with the DataContract attributes.
It is working pretty smoothly. Had some issues with async in silverlight, but got it working with some aid from the folks at MS.
Thx