Whoops, my reply originally only went to Ray: There are a couple of goals here that I don't think are mutually exclusive: One goal is that we don't have functionality "locked away" on the server side where it can only be used by Java programmers. This was the situation for a large proportion of CLE development where designers could only throw mockups over the wall and had no chance to iterate the UX with a fast feedback loop. The phrase "front-end engineer" was not yet widely used at that time.
The other goal is that a smart developer should be able to build something quickly on top of the platform. This goal should not imply that server-side code is off limits to this developer. I think the success of Ruby on Rails is in part due to the ease with which a single developer can be productive through the entire stack: markup, CSS, business logic, the domain model, and automated tests. I think we should characterize the separation we're pursuing not in terms of server-side vs. client-side, but in terms of platform development vs. application development. In other words, we are successful when a curious student of software engineering can create an application without needing one of OAE's committers to put something in. Our service APIs (whether in the server or accessed over http) are hugely important to this latter goal, but to date they have not gotten much design attention. I'd like us to remedy that. Zach On May 7, 2012, at 1:06 PM, 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 _______________________________________________ oae-dev mailing list oae-dev@collab.sakaiproject.org http://collab.sakaiproject.org/mailman/listinfo/oae-dev
