Looks like a whole can of worms exploded here over the weekend.... Here are some of my cherry-picked comments:
On Jan 5, 2008 10:04 AM, John Mettraux <[EMAIL PROTECTED]> wrote: > 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). > > You're right. Taskr is not a workflow/BPM API. I think maybe I had made things confusing because I previously I spent a lot of time talking about Fluxr, which WAS an attempt at a RESTful workflow/BPM API. Taskr is not the same as Fluxr. Taskr is just a wrapper for the OpenWFEru Scheduler and has almost nothing to do with OpenWFEru's Workflow Engine project. I brought Taskr into the conversation because 1) at its core it uses OpenWFEru's scheduler and so it may be of some interest to those already familiar with OpenWFEru in general, and 2) I see it as a component in a larger REST-based service-oriented architecture. The latter being the case, Taskr likely deals with some of the same hurdles that we'll have to cross if we're to make OpenWFEru's Workflow Engine a RESTful service. Interoperability is of obvious importance here, so I'm interested in what the rest of you think about how Taskr presents itself (e.g. is Taskr's way of dealing with authentication "good enough"?) Now, aside from the above, I get the feeling that John is not especially excited about all this RESTful stuff -- not the way Pat and I are anyway. Maybe we haven't made a good case for it, or maybe it's just not really how John envisioned OpenWFEru evolving. Either way, it would be tough to try to get this off the ground unless John is equally interested in seeing it happen. Furthermore, I think that it would be a mistake to see this RESTful stuff as just an API -- a way of talking to the OWFE engine (and I think that's how John sees it). Coming up with this API demands a fair bit of reflection back on the engine itself (i.e. thinking about it in terms of 'resources'), and I personally found this exercise unexpectedly frustrating. I'm still not sure if this is because I just don't get John's architectural decisions (likely because I'm fairly new to thinking about BPM systems), or because there are some dubious semantics hiding in there. In any case, as it stands, I think building a meaningful RESTful API around OpenWFEru may be difficult unless some conceptual accommodation is made in the underlying system (and this is 1) hard, and 2) not fun). In regards to the original topic here: John, I agree. A centralized authentication/authorization system in the style of restful_authentication would be a good, useful thing, and the "standalone project" you're referring to may turn out to be RubyCAS -- at least this is how I see the project evolving. Support for OpenID is already in the works, as is a RESTful version of the CAS protocol. This might make both you and Pat happy, in that RubyCAS would be able to authenticate against OpenID, while providing a restful_authentication-like interface. (Support for OpenAuth may be a problem, but in any case I think we should deal with authentication before authorization, since it's possible can get by with just the former). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
