Chris expressed my intent well. I will, however, add that I think that the first few years of this project gave far too much priority to an extreme interpretation of "UI-agnostic api": the goal of enforcing a UX-design-agnostic client-server API which _forced_ all application logic into browser-hosted code.
I believe that most of the project issues I've seen can be linked to this surmised goal. And I believe that three and a half years of highly skilled labor have conclusively proven the goal to be untenable, at least for deployments at the scale and complexity of the University of California or NYU: the results are non-performant, unmaintainable, and too tangled even to call "developer-friendly." (Unlike, say, vanilla Sling, which at least presumed server-hosted scripting of functional logic.) If there is disagreement between us, I expect it rests here. My employers want reasonably rapid delivery of scalable CLE-plus functionality integrated with campus services and externally-hosted applications. Exclusively browser-hosted-JavaScript implementation of all such functionality never appeared on their list of goals, and I no longer consider it compatible with their list of goals. Best, Ray On 5/6/12 11:45 AM, John Norman wrote: > OK, well in my mind what you just described remains a hard separation, > just higher up. The key from my point of view is to have a sufficiently > UI-agnostic api that we can live up to the claim that 'if you don't like > the UI you can throw it away and build your own'. Functional api calls > at a higher level needn't threaten that unless they get so high level > you can't in any practical sense reuse the apis for any purpose other > than supporting the default UI. > > Thanks > John > > On 6 May 2012, at 16:36, Chris Tweney wrote: > >> John, I don't think anyone's advocating removal of the low-level APIs >> that we currently have (user creation, content nodes, ACL setting, >> etc). The "hard separation" refers to the (more or less) complete >> ignorance of business logic on the server end in current OAE >> architectural practice. >> >> Ray's point is that we should *also* have higher-level feature APIs >> that support some business logic (eg worlds, sakaidocs). These >> higher-level APIs would have the same form as the low-level ones -- >> JSON and/or HTML feeds with a RESTful syntax. They'd just be >> better-educated and encapsulate more business logic. That will enable >> the UI to do more with fewer requests. It will also permit other >> clients (eg mobile) to be developed against the same set of APIs. >> >> At another level, "hard separation" may also refer to team structure >> and project management. I think there's a growing consensus that the >> UX and server teams should work much more closely together -- even to >> the point of merging into one team that splits up into >> feature-oriented subteams. >> >> -chris >> >> >> On Sun, 6 May 2012 07:30:28 +0100, John Norman <j...@caret.cam.ac.uk >> <mailto:j...@caret.cam.ac.uk>> wrote: >> >> From the published notes (referring to Ian's blog): >> >> Ray: The re-write maintains the hard separation between the UX and >> the server. If we can help it, we should bring these two together, >> so we can be feature oriented, and involve the entire stack when >> we want something new. >> >> This is of great concern to me as the notes don't indicate that >> the view was challenged. I regard the separation (or at least the >> core role of the data api) as a fundamental requirement of the >> product. >> John >> >> > > John Norman > Director - CARET > University of Cambridge > j...@caret.cam.ac.uk <mailto:j...@caret.cam.ac.uk> > +44-1223-765367 > > > > _______________________________________________ > oae-dev mailing list > oae-dev@collab.sakaiproject.org > http://collab.sakaiproject.org/mailman/listinfo/oae-dev _______________________________________________ oae-dev mailing list oae-dev@collab.sakaiproject.org http://collab.sakaiproject.org/mailman/listinfo/oae-dev
