! 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?