On Jan 5, 2008 11:28 PM, Pat Cappelaere <[EMAIL PROTECTED]> wrote: > > John, > > I am obviously not making much progress with influencing OpenWFE design and > this is getting frustrating...
What is frustrating to me is that there seem to be no way to separate concerns here, our discussions about this RESTful stuff are extremely confusing, no clarity. OK, I give up. I think I will simply let you commit on Kisha and let you do whatever with it. If it's convincing I'll try to help maintain it. > As a follow up to this email, Let me try again using different words: > > There are 2 problems to solve with the RESTful API. For the record, those > problems have been solved and documented in existing specs. > > Problem 1: user identification and authentication. Any rail app has that > need. Code/pluggins exist to handle that piece. > > Problem 2: when you want to execute a workflow remotely, you need to > identify yourself but then delegate your authority to the workflow to > (potentially) allow it to access other web services on other sites... > > Problem 1 has been solved by OpenID 2.0. There is even room for attributes > exchange or AX (for instance: access permissions) if required by the > application (but AX is certainly not something that is needed within > densha...) > > Problem 2 has been solved by Oauth 1.0. This problem can be further > simplified if you make some other assumptions such as pre-approved > transactions. The discovery portion is still tbd at this point but it is not > critical. Since the work happens in the headers, there is very little > effort (if any) to support it. Seems like Problem 2 is a GeoBPMS problem (I have already said it two or three times). > My main concern is that this project does not seem to foster cooperation nor > intends to look at interoperable solutions. If it is "Not Invented Here", > let's not use it seems to be the current mantra. The mantra is/was let me build something with very limited authentication/authorization for now and then add to it. Auth/Auth is currently 2 lines of code in Kisha... > We are at the point of having 3 or 4 different "RESTful" APIs that have no > legacy nor heritage. Just a clarification the Taskr RESTful API is not a "workflow/BPM" API, it's a job/task scheduling API (maybe I simply don't get it). > There are 2 organizations that are interested in workflow interoperability. > This community has a unique opportunity to make a difference. > > But is there a true intent in building such a community around OpenWFE? Do > we want to make it interoperable with other engines that are used for > solving real business problems? Do we have the resources to make that interoperability happen ? Maintaining open source code is hard, it requires passion. It's very difficult to manage the egos of each participant. Almost all the other BPM/workflow open source projects are company backed, communities are tiny here, not mainstream. > I cannot answer that question. Rather than being spoon-fed code from > various parties, I would like to see everyone interested come to the table > and start the documentation process of that API (at least). Then we could > go off and implement the various needed components that may or may not be > part of core (Densha, Kisha, Fluxr, Matelot...) I will simply open Kisha to you and let you do whatever you want with it. I would like you not to touch to the core OpenWFEru, and to Densha which you don't need. Best regards, -- John Mettraux -///- http://jmettraux.openwfe.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/openwferu-dev?hl=en -~----------~----~----~----~------~----~------~--~---
