! Notes BRIDGE/VT-Portal Integration
_
Security
- Interactive client:
-- Currently includes no encryption support. Passwords are sent in clear text.
-- Initially will just implement encryption for authentication message, then use VT Middleware's EDDO library to authenticate PIDs.
-- Eventually need option for encrypting all message traffic
- Web client:
-- Currently uses basic HTTP authentication (no encryption)
-- Need to determine servlet engine (currently Jetty) https support, get certificate?
--- Or can Authportal single sign-on take care of this?
-- Will need cookie-based session tracking
Scalability
- Non-blocking I/O. Currently we are limited to less than 100 simultaneous connections, depending on OS configuration.
- Scalable account management. Account provisioning is currently not automated or scalable for "real" accounts that need to have flexible, persistent storage.
- Session tracking enhancements. Each client currently maintains a replica of a list with information about every other client. Scalability would be a problem if we get to 100s of simultaneous connections.
- Fix known "server-killer" bugs, embedded object recursion problems in particular. (None of these are difficult -- they just haven't been a priority.)
Applications
- RSS feeds (*http://www.ietf.org/internet-drafts/draft-nottingham-rss2-00.txt*)
-- Discussions/blogs/calendars, other objects that lend themselves to RSS summaries
-- History, other async awareness for sets of objects
-- User lists?
- Channel-compatible XML rendering of wiki text objects
- New tools aimed at custom channel creation?
- Embedded applet-based client?
- Revive place-based interaction ideas? [Con]
Questions:
- Details on "Custom" channel content format? uPortal-specific API? (and "Simple XML Transformation" format)
- Beyond initial testing (for which we can set up uPortal on a server in the lab), how would deployment work?
-- How flexible is uPortal w.r.t. dynamic sets of available channels?
- Any stats on most popular channels? Frequently requested channels?