What is TeamWorks engine “twsengine”

twsengine is a core server, thanks to ZODB as main storage of the applications components objects and logic organized in folders and ZODB ZEO to provide access to these objects over a network and to Twisted web for serving client requests in JSON format, highly available and scalable general purpose and database applications can be build on and serve clients applications by REST API accessing the objects by urls.



twsengine applications are organized in services, the default service, is a system service containing the authentication and the storage service. Each object security is managed by profiles that can have contexts access, each service has it's own profiles and each object can have it's own context access, but default to all objects contexts access are [read, write, execute, admin] .
For Example we have a service: service1 with profiles guest, user, admin
(at the system level these profiles would registred as service1-guest, service1-user, service1-admin)
on a service object1 located at /service1/object1
service1-guest user would have contexts access; [read]
service1-user user would have contexts access; [read, write]
service1-admin user would have contexts access; [read, write, execute, admin]
any action on objects especially over the network must be registered with the contexts access:
/service1/object1
    actions   context context view
    get        read     view (default)
    save       write    view (default)
    enable    admin   manage
    disable    admin   manage
    calculate execute view (default)

*to enter the “manage” view the user must authenticate and have admin profile.

possible scenario:
The user make a server call without authentication, he would have automatically the system-guest profile but not the sercice1-guest
the action handle('/service1/object1', 'get', …) will fail
the guest user can be the guest of the system but not the guest of the service
possible scenarios:
1- if we want that service1 to be publicly visible we resister system guest user to have 
serveice1-guest
2- if we mean by guest a registrated user of the system we resister system user to have have serveice1-guest
3- we resister a a user with profile service1-guest to have read access on object1
now the action handle('/service1/object1', 'get', …) will be successful

but the other action eg: handle('/service1/object1', 'save', …) will return access error in case of case of system-guest, suggest authentication or registration.

Data base services

The main idea is to have data folder objects (relate to database table or noSql catalog/namespace) that do not aware in which database they are stored, and by interface they think they are simple folder objects.
the data base service host a special object called storage, (different storage objects can plugged for example postgres storage or odbc Maxdb), and then assign the data service to use the storage object as default storage function set_default_storage called in manage view.
The data objects think they are simple folder objects for example:
we have a table invoices linked with a data folder invoices
we can call:
handle('/dataservice1/invoices',list_items, params) to get the list of invoices params can contain the filters to use, and then if there is items
handle('/dataservice1/invoices/item1/reports',list_items, params) # to get the list of available reports
or handle('/dataservice1/invoices/item1/collections/expenses',list_items, params) to get the list of expenses
or
or handle('/dataservice1/invoices/item1/actions',list_items, params) to get the list of actions that can be handled by this data base item

Any user session must succeed or fail , connections of services data bases will be connected to the main session transaction via transaction data manager, so if any call fail in any of the services fail, all transactions will roll back and no change will occur. S
o at any time the user session at call must succeed or die.
  
to be continued ...


What is TeamWorks desk: “twsdesk” and “twswebdesk”

“twsdesk” is a pyside (http://pyside.org) gui application for hosting desktop gui applications, developed to host the client for twsengine.
The client log to the server and query the accessible items for example: it enter the root application folder and do:
 handle('/', 'login', user_id=user, password='*****') 

if log in successfully it will request handle('/', 'list_items_descriptions', params) *params can contain filters
it will receive in this case the accessible services description:
the description contain the name, title, text description, icon name component name and component_view_names … .
By the view names will try to find a component to represent the item visually if not it search for the visual component element. Each component has it's own storage folder in the context of application context to cach or save user settings.




“twswebdesk” is a desk browser client for twsengine built under pyjs (in a very alpha stage).

Todo: write standalone clients library javascript, php
The main libs:
    python           http://www.python.org   
    Twistedmatrix http://www.twistedmatrix.com
    zodb              http://www.zodb.org/
    pyjs               http://pyjs.org
    mx libs           http://www.egenix.com
    pyside            http://www.pyside.com