Bongiovi DPS

Reply To: DPS 2.0 Redesign Mission Statement

Forums Bongiovi DPS 2.2 DPS 2.0 Redesign Mission Statement Reply To: DPS 2.0 Redesign Mission Statement

#64039
mikeyward
Member

Hmm. Interesting problem. After considering it with my team, a few options bubbled to the surface:

  1. DPS could write to a globally-readable common-language (JSON, etc.) file a list of the categories, which routes are currently selected for them, and which routes are available to them. This file could be updated any time the routes change. Pros: relatively easy to implement, totally cross-platform. Cons: possibly fragile implementation, as client apps would probably have to hard-code the file’s location.
  2. The custom URL protocols could define a mechanism by which a response url-scheme could be passed in as a value to the request, such as bongiovi-dps://request-routes/?return-url-base=”my-cool-app”&request-guid=”…”. Notice that my sample URL has also passed in a request-guid that would be used by the client app to pair outgoing requests with incoming responses. DPS could then, upon completion of the request, post an application URL using the passed-in base and supplying the response as a URL-encoded JSON object: my-cool-app://<request guid>/?json=”…”. Pros: relatively easy to implement, totally cross-platform and non-fragile. Cons: Depending on size in bytes of response, may not be performant. Then again, this could be mixed with the above Option 1, where the response payload is written to disk, and the response url only passes in a path on disk to the response payload. Lots of tweakable options here.
  3. DPS could implement one of several RPC libraries, such as Cap’n Proto (http://kentonv.github.io/capnproto/) or ZeroRPC (https://github.com/dotcloud/zerorpc-python). Pros: very performant, cross-platform. Cons: steep learning curve, not exactly easy to implement.

Do any of those options sound reasonable?