+1 I don't recognise Ray's characterisation of my aspirations.
J On 7 May 2012, at 19:06, Clay Fenlason wrote: > Is there a non-extreme form of UI-agnosticism that you think is > tenable? If the complaint is just about an abusive fundamentalism, > fine - I can believe that and hold to the principle at the same time > (which I do). > > There are two ways in which the principle seems critically important > to me. I'll be happy if they're both orthogonal to the point you're > making: > 1) Our APIs should support lightweight developers of widgets and > mobile apps, and in order to be usable they need to present logical > abstractions that aren't generally cluttered with details that assume > a particular UI > 2) We need to be able to affect design changes (provided they don't > introduce new capabilities) without altering Java services, or there > will be inertial resistance to design iterations > > If the point is just that the business logic on the front end is > poorly conceived, that better services will incorporate more business > logic, and that our teams could be better organized - all that sounds > fine to me. It's not a diagnosis that threatens my embrace of what I > call UI-agnosticism (outlined above). > > ~Clay > > On Mon, May 7, 2012 at 12:44 PM, Ray Davis <r...@media.berkeley.edu> wrote: >> 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 > _______________________________________________ > oae-dev mailing list > oae-dev@collab.sakaiproject.org > http://collab.sakaiproject.org/mailman/listinfo/oae-dev John Norman Director - Information Technologies and Applied Research in Educational Technologies University Library University of Cambridge 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
