Summary
This is simply an inventory of all the Cosmo related work items (we have collected so far) that can be used to build the 1.0 roadmap. We expect to be missing some which is why we have done this exercise. Keep in mind that Cosmo is now both the server as well as the web client UI. A couple of important points about this inventory....
- This list is at the "high-level workflow feature" granularity
- This list does not yet reflect any particular prioritization
- We have grouped all the items according to the target user they satisfy
- Chandler Casual Collaborator
- Hosted Service (this includes admin ui and non-gui requirements)
- Other Cosmo users - platform devs etc (this may in fact be several users but I will let Ted tease this out)
- One "stickie" =~ 2 weeks of work
- The stickie estimates are just "seat of the pants guestimates" for planning purposes. We will not hold people to these swags.
- Within each list item we identify whether or not it's front-end work (Matthew, Bobby) or server work (BCM) and if it has any Chandler desktop dependencies.
Chandler Casual Collaborator
Stuff we think we have to do
| Feature | UI Stickies | Server Stickies | Desktop Dependency | Priorities | Questions |
|---|
| Support new sharing format | | 1 | Sharing format design and implementation work | P1 - We have to do this | |
| Handle the unified (magic) URL users can just click on. (Note: depends on the implimentation.)* | 1 | 1 | Client has to be able to publish and return new URLs | P1 - Another thing required to just make things work | |
| Delete and remove | 1 | 0 | | P1 - We won't distinguish between delete and remove, we just have delete. No undo. | |
| Subscribing to local collections* | 3 | 0* | | P1 - Another thing that just has to work. | *bcm- need more info about the feature but doesn't seem to require any server work |
| Read only view* | 2 | 0 | | P1 - If you receive a read only ticket, we need a read only view. | The amount of time for this will depend on how many other types of views we also implement (e.g., non-calendar, calendar-table-view, etc.) -- MatthewEernisse |
| Edit update workflows - mail to: link* | 1 | 0 | | P1 - This isn't very hard to do. | |
| Viewing other people's Free-Busy | 1 | 0 | | P1 - Why is this different than just subscribing? | already implemented in server. Does this show separate, title-less lozenges, or a single unified block? -- MatthewEernisse |
| Round trip email conf for new accounts | 1 | 1 | | P1 - Jared would like this | |
| Password change UI | 1 | 0* | | P2 - Is this really 1 stickie | *bcm- ui to change password already exists, needs to be integrated with calendar view and possibly redesigned. Do we implement a separate UI for password change, and then later move it into a 'My Account' section with user prefs, or do we stub out a unified UI for both together? -- MatthewEernisse |
Work items to support more than just events
| Feature | UI Stickies | Server Stickies | Desktop Dependency | Priorities | Questions |
|---|
| Multiple item view - displays diff types of items | 3 | 0 | | We already have this for calendar today, would need for other types | There can also be different types of multiple-item view -- e.g., calendar-view versus table-view for displaying multiple events. -- MatthewEernisse |
| Single item view - displays diff types of items | 2 | 0 | | Don't have this for calendar event so at a min would have to do single item view for 1 type | |
| Stamping in server data model | | 2 | | | |
| Not hardwired to events - serialization between Cosmo and the browser | 2* | 0 | | | *only if we have to implement something which reads "morse code"(DAV++) on the client side. if we just use JSON this becomes easier. -- BobbyRullo |
| Not hardwired to events - client side data model | 3 | 0 | | | |
| Not hardwired to events - changing app to use new api | 3 | 0 | | | mde - What is the difference between this and the one below? -- BobbyRullo IIRC, This one is changing all the places in the UI code that use the old API to use the new one. The one below is designing and creating the new API to use in the UI code (e.g., createCalendar becomes createCollection or so). -- MatthewEernisse |
| Not hardwired to events - changing api on front end | 2 | 0 | | | |
| Not hardwired to events - stamping support in client side data model | 2 | 0 | | | |
| Table view work | 3 | 0 | | Only need the table work if we are supporting other than calendar events | |
Stuff that could be removed from Preview (Beta) entirely
| Feature | UI Stickies | Server Stickies | Desktop Dependency | Priorities | Questions |
|---|
| Preferences | 1 | 1 | | P3 - We could potentially punt this and not have UI preferences | |
| Search table view | 1 | ?* | | P3 but higher in priority than quick item entry | *bcm- don't know what this is. Is this a table view with some search filters? -- MatthewEernisse |
| Quick item entry | 2 | ?* | | P3 but less important than search | *bcm- don't know what this is. If this involves the natural-language stuff, we could probably do the regex stuff on the client. -- MatthewEernisse |
| URL & password for shared collections | 1 | 1 | Some implementation work on the client | P4 - We decided to put to punt this one. | |
- PPD Comments and Questions
- For the first group of P1 & P2 items - can we get more accurate stickie estimates. When we say 1 stickie is it really 2 weeks or just a matter of days?
- We would like to find out the stickie estimate for just doing the calendar event single item view. The estimate above includes all the work for supporting the other types of items so we wanted to know how this would change if we just did events only?
- We are considering the option of only supporting events for Beta. That eliminates all the other work items for retro-fitting the architecture, having a table view etc. Currently there are too many stickies here to fit into Beta but it doesn't seem like there is another other stuff for the client UI. Not sure what to do about this. Perhaps we can stage some of this work, are there alternatives here? Could we also maybe look at the scoping a bit more closely...is there some subset we can do or do we have to do all of it?
Admin and Hosted Service
Admin
| Feature | UI Stickies | Server Stickies | Notes | Questions | |
|---|
| Work to merge the current admin UI to the web UI | 1 | 0 | P3 - no reversion | | |
| Account management UI | 1 | 0 | move out of admin | | |
| Space usage info | | 1 | P1 - To assemble report of top disk space users. Bug#7051. | bcm- i assume this includes all quota-related implementation | |
| Disable all user access | | <1 | P3. Bug#7046. | | |
| Disable access for single user | <1 | P2. Bug#7043. | Admin UI? | |
| Detailed logging | | ?* | 0.5 P4 - (nice to have) HTTP transaction generates a compact log entry; additional trace+debug info | *bcm- need more requirements detail | |
| URL scheme is stable | | ?* | P2 - Not sure if this is actually work for Cosmo | *bcm- need more requirements detail | |
| CMP replacement | | 0* | P4 | *bcm- not likely to happen, though some small protocol updates may be in order | |
| Network-based backups | | 1 | P2 - May be little work after sharing format implementation. Bug#6264. | | |
| Real-time metrics | | 1* | P4 - JMX-based; maintainance of key "as of right-now" metrics | *bcm- need requirements (specific metrics, frequency of updates) | |
| Trigger for password reminder | | ?* | P4 | *bcm- need more requirements detail | |
| Admin reports | | ?* | P4 - Way to see malicious activity | *bcm- need more requirements detail | |
| Security review | | | P2? - Check for XSS (cross-site scripting attacks), SQL injection, other classics | | |
| Accounts can share email address | | <1 | P4 - Needed for real-world usage. Bug#7055. | | |
| Data preservation during updates | | 1 | P1 - Mechanism to support schema evolution, and to update between Cosmo releases | | |
| Admin op to nuke user's data | | <1* | P4 - Needed to implement network backups and other admin ops | *bcm- need more requirements detail | |
| Retrieve encrypted password for account | | 0* | P4 - Needed to implement network backups | *bcm- redundant; part of "network-based backups" feature | |
Multiple Database Servers
After discussions with Jared, there are a number of work items on the list that, once we switch to the hibernate backed Cosmo, will just have to work. Since we don't yet know if we will be using multiple databases for the Beta, some of these items could be deferred but since we are planning beyond Beta, I wanted to include them. P1
| Feature | UI Stickies | Server Stickies | Notes | Questions |
|---|
| Database indirection | 1-2 | Support accounts on multiple dbs |
| Centralized profile | <1 | Use one db for profile info, another for actual user data |
| Get list of all users | <1 | If we support multiple dbs, we need a way to do this |
Multiple App Servers
In the way that there are a set of features needed to support multiple dbs, if we support multiple app servers we may need the following. P2
| Feature | UI Stickies | Server Stickies | Notes | Questions |
|---|
| Web session clustering | | <1 | | |
| Load balancer integration | | <1 | Probably little-to-no Cosmo work | |
| Cosmo using clustered Tomcat caches for key objects | | <1 | Needed with hibernate | |
| Stateless application | | ?* | Support any transaction coming into any app server | *bcm- this is an architectural principle not a feature |
Other Cosmo Users
This is the inventory of other Cosmo work needed to support platform users, people hosting Cosmo etc. We are currently in the process of teasing out these users and putting together this stickie list.
| Feature | UI Stickies | Server Stickies | Notes | Questions |
|---|
| Server item versions | <1 | P2(JRR) - Needed to avoid data reversion after backups | |
| CalDAV final draft | | 2-3 | ACL support at least | 2-3 with acl, 1 without |
| Alarm messaging | | 1 | Open mechanism to subscribing to server-fired alarms | |
| CardDAV? support | | 1 | Low-hanging fruit with code available | |
Log In