Potential FlowTalk SUM
This page is for discussion around the development of a SUM. Please add comments.
Initial discussion was with John Norman, CARET. He was interested in looking at the base level services within Sakai and experience with building on these. The FlowTalk project tried to use the Sakai APIs to create a new interface independent messaging and workflow service.
NB: A CARET Sakai SUM is on the way, so a FlowTalk SUM can reference this.
Notes:
from chat with Antranig Basman, CARET, on FlowTalk and interface with Sakai
- FlowTalk was about a more flexible discussion platform
- FlowTalk Architecture
- http://www2.caret.cam.ac.uk/flowtalkdevwiki/Wiki.jsp?page=FlowTalkCode (see Antranig or Lyle for this document)
- Background
- flexibility of data store (storage agnostic, abstracted)
- wanted host neutral, Stanford coursework and Sakai (must behave both in same, understand user and group structure, works smoothly)
- flexibility of ped exercise, behaviour
- eg. until users have entered answers to all questions they can't see others answers
- should follow JVM integration and WS
- originally for end user web services, but respecified the work as WS for hosting as all the use is done through VLE (a server)
- integrated mail and discussion tool
- Uses these things
- presentation framework - transformation (RSF, migration from JSF)
- designers had an important role in the tool deployment
- not in the hands of developers to do this, UI changes
- difficult to get flowtalk into production in Sakai
- deployment "slog" (conditions, testing, deployment)
- one or more flowtalk serving multiple Sakai imps
- problem connecting production Sakai with non-prod Flowtalk
- negates the benefits of having a WS
- coop with admins of Sakai for up-time is difficult
- Sakai is just a webapp, but really just something more like tomcat, a place you can deploy servlets
- Created a glue package, which is a FlowTalk tool but does WS calls out and in
- outgoing calls: request across, presentation back
- RSF was important here, sits at the FlowTalk end
- HTML templates for each type of client it can use, output is completely right from the Sakai end (Sakai style guide)
- send out client type, backtalk URL
- FT - mapping from user groups on host (standard roles and superadmin), distinguish superadmin with the others (not site admin)
- access, maintain (standard pattern)
- this is the level above Sakai roles (the superadmin)
- incoming calls: permissions
- securing this channel?
- WS
- inappropriate granularity of WS calls in Sakai
- needed bulk information for Sakai sites
- used
- pull into FlowTalk, update cycle
- staleness of AuthZ information
- doesn't use messaging or content management so does work with search
- separate webapp servlet
- gain access via Spring to Component Service
- Tool glue WS -> FlowTalk dispatcher -> !Flowtalk WS ->
- send: Back service URL, Client ID, Client type, Auth timestamp
- send: really just a servlet request with URL params (GET)
- Developers need Sakai programmers cafe to get started - Aaron's setup stuff
