Dec 2 we met to talk about the current state and unknowns in our server planning... these are the highlights since I didn't take detailed notes.

(If anybody remembers other details please feel free to add them)

Discussed current architecture

• Link to SharingArchitecture passed around before meeting
• Morgen discussed how the 0.4 implementation doesn't use WebDAV collections and how he plans to use collections
• Discussion of how a WebDAV resource will map to a Chandler cloud -- we will package each cloud into a single WebDAV resource so that we don't have to keep multiple resources consistent with each other.
• Brief discussion on whether to use properties to store Content Item information or whether to put in an XML body for now. The use of body may be a temporary step.
• Current code has many performance problems, some in the use of repository (item history) calls, and some in use of WebDAV -- we should be able to make it MUCH faster
• Open issues recognized around how to share filtered collections without limits on what the filtering should look like, but this isn't a goal even for Kibble, and certainly not for 0.5
• More design work needed on what's the correct or expected behavior sharing filtered collections
• Some ideas tossed around on access control and sharing filtered collections where the sharees can modify the filter -- if we always assume the most negative ACL on a Content Item until it's shared or the user takes explicit action to make it more publicly readable, then we can allow other users to modify filters without security concerns (however there are still plenty of other concerns)

Discussed current requirements

• Link to ServerProductPlanning passed around before meeting
• We went through these requirements and discussed which of them were already met by Slide, and which requirements weren't met by Slide
• we discussed how those requirements affect how we would find a server developer to take Slide and add feaures to meeet those requirements
• we discussed the alternate plan of finding a server developer to champion some other software base or architecture to meet those requirements (difficult to find something else that has as many features already and scales so well)
• Ted explained how he'd be dubious of any proposal that didn't involve Java, because he'd be worried about time to develop (if it involved C or something lower-level than Java) or poor scalability (if it involved Python or something higher-level than Java)

-- LisaDusseault - 03 Dec 2004