::Workspaces API
-
::Workspaces from the very beginning was a framework which was supposed to talk with large number of third-party applications. In that sense, the framework itself doesn't really know what the application is doing, application just need to display itself in an iframe & obey to some small protocol. Let me describe in short detail some internals how the framework interact with applications. We have a list of registered applications, whereas each application is described by URL to its server, name, author, icon, description, logo and a bunch of similar attributes. Currently general public cannot register their own applications, although that is going to change in the future. The application URL given to ::Workspaces framework will be used for secure server-server communication between framework and the application servers. Whenever new workspace gets created and user want to add application to that workspace, framework will send 'install instance' kind of request to the application. In such approach, 'application instance' is an entity of, well, application instance within a workspace. Framework doesn't care what 'instance' represents. In case of ::GitMachine, 'instance' is git repository. For ::Tasks it is a task tree. For ::Docs it is a number of texts (currently artificially limited to 1, but in future that will be just a wiki). If one would adapt e.g. Redmine, Bugzilla or Jira to obey our protocol, the instance would be just a Redmine project, or something like that. Framework and application servers do exchange a number of informations about the applicaiton instance, e.g. what iframe URL should be, who is owner, who has access to that instance, is the instance private or public, etc. The whole protocol is engineered to be fully secure, so both parties can be sure that the traffic between them is not tampered with. That leaves us to browser side. When framework displays application instance, all the framework knows is the URL of the instance. Iframe gets created and pointed to the specified URL, application is supposed to display the content of the specified instance there. That is done in a secure way as well, so during the initial load framework passess all necessary credentials so application server may be sure that the requesting user really have access to the resources. With today's browsers if one want to securely display HTML content from other sites, the basic approach is to use iframes. They nicely separate applications from each other and from framework. Unfortunately, they bring lots of
-
::Workspaces from the very beginning was a framework which was supposed to talk with large number of third-party applications. In that sense, the framework itself doesn't really know what the application is doing, application just need to display itself in an iframe & obey to some small protocol. Let me describe in short detail some internals how the framework interact with applications. We have a list of registered applications, whereas each application is described by URL to its server, name, author, icon, description, logo and a bunch of similar attributes. Currently general public cannot register their own applications, although that is going to change in the future. The application URL given to ::Workspaces framework will be used for secure server-server communication between framework and the application servers. Whenever new workspace gets created and user want to add application to that workspace, framework will send 'install instance' kind of request to the application. In such approach, 'application instance' is an entity of, well, application instance within a workspace. Framework doesn't care what 'instance' represents. In case of ::GitMachine, 'instance' is git repository. For ::Tasks it is a task tree. For ::Docs it is a number of texts (currently artificially limited to 1, but in future that will be just a wiki). If one would adapt e.g. Redmine, Bugzilla or Jira to obey our protocol, the instance would be just a Redmine project, or something like that. Framework and application servers do exchange a number of informations about the applicaiton instance, e.g. what iframe URL should be, who is owner, who has access to that instance, is the instance private or public, etc. The whole protocol is engineered to be fully secure, so both parties can be sure that the traffic between them is not tampered with. That leaves us to browser side. When framework displays application instance, all the framework knows is the URL of the instance. Iframe gets created and pointed to the specified URL, application is supposed to display the content of the specified instance there. That is done in a secure way as well, so during the initial load framework passess all necessary credentials so application server may be sure that the requesting user really have access to the resources. With today's browsers if one want to securely display HTML content from other sites, the basic approach is to use iframes. They nicely separate applications from each other and from framework. Unfortunately, they bring lots of
Hi Kamil, Me and Kornfeld Elyahu Peter had the idea of developing a ::Task mobile client. The big deal about it would be that we write it in Qt, which would make it available for all major mobile and desktop OSes with a single codebase. Qt isn't exactly awesome when it comes to consuming Web Services, so a SOAP API would be the best idea. About the API in general: I'd rather define APIs for each Workspace Application (Docs, Tasks, Code) and then have a minimal global API for the workspace itself (e.g. the Workspace API just allows you to see what applications are installed and then you connect to, for example, the Tasks instance by using the Tasks API). This would also allow continous integration of the API where you first develop the Workspaces API and then the API for Tasks, then the Code API and so on.
I will never again mention that Dalek Dave was the poster of the One Millionth Lounge Post, nor that it was complete drivel.
The console is a black place [taken from Q&A]
How to ask a question -
Hi Kamil, Me and Kornfeld Elyahu Peter had the idea of developing a ::Task mobile client. The big deal about it would be that we write it in Qt, which would make it available for all major mobile and desktop OSes with a single codebase. Qt isn't exactly awesome when it comes to consuming Web Services, so a SOAP API would be the best idea. About the API in general: I'd rather define APIs for each Workspace Application (Docs, Tasks, Code) and then have a minimal global API for the workspace itself (e.g. the Workspace API just allows you to see what applications are installed and then you connect to, for example, the Tasks instance by using the Tasks API). This would also allow continous integration of the API where you first develop the Workspaces API and then the API for Tasks, then the Code API and so on.
I will never again mention that Dalek Dave was the poster of the One Millionth Lounge Post, nor that it was complete drivel.
The console is a black place [taken from Q&A]
How to ask a questionThanks for the writeup. Indeed Qt might offer nice portability, though at the cost of not looking natively on any platform :) I must admit that I didn't saw that SOAP request coming. It certainly emphasises the need for separation of the API from the transport layer. At this moment you probably considered just basic tasks management operation, did you had any more complex use case in mind as well?
-
Thanks for the writeup. Indeed Qt might offer nice portability, though at the cost of not looking natively on any platform :) I must admit that I didn't saw that SOAP request coming. It certainly emphasises the need for separation of the API from the transport layer. At this moment you probably considered just basic tasks management operation, did you had any more complex use case in mind as well?
Kamil Burzynski wrote:
though at the cost of not looking natively on any platform :)
I second that, but IF I'm going to write a Task App, I'd probably go with QML[^], and look to style the controls in a way that they look like CodeProject, and not a native platform.
Kamil Burzynski wrote:
At this moment you probably considered just basic tasks management operation, did you had any more complex use case in mind as well?
I'd say going for the ::Tasks app as first feasibility would be enough, just as proof of concept. If we get it to run and see that it works we can go ahead to more complex applications.
I will never again mention that Dalek Dave was the poster of the One Millionth Lounge Post, nor that it was complete drivel.
The console is a black place [taken from Q&A]
How to ask a question