Developer Platform Roadmap Brainstorm

Sheila, Katie and Ted met to discuss the support for parcel development today and potential roadmap/plan in the 1.0 timeframe. We brainstormed in a number of areas...

• What categories of developers are there and what would they be most intersted in.
• Ideas for staging and supporting this work between now and 1.0 and post 1.0.
• A few ideas on parcels we would like to see developed if we have resources from all these groups.

0.6 Summary

In 0.6 our goal was to enable someone to add a Flickr type parcel without assistance from an OSAF developer.

• At high-level we support the ability to...
  • define new kinds
  • pulling data from internet and adding to repository in some formulaic way
  • display in chandler

• Can Do:
• add a new kind of item
• associate a detail view with that kind - attributes
• customize the content model so it shows up in the summary table view
• columns are fixed but you can control the data that appears
• create menu items and handlers - typical is to add a new collection to the sidebar
• write a wakeup caller (background task) - grabs data and puts in repository.
• menu item - simple dialog to collect information
• integration with existing kinds - stamps

• Can't Do:
• stamp as the new kind
• interact with app bar filter
• set preferences
• hardwired preferences
• summ table view is restrictive - customize columns
• a truly custom detail and summ table view
• cosmo server - documenting format and letting people get it off there.
• plugin for evolution and get calendar data -
• headless chandler - no gui - you can write servlets (not documented ready for people).
• custom attribute editors
• custom sidebar
• link to view that doesn't fit into virtuality - repository viewer
• creating a new kind - haven't explored boundaries of linking kinds, relationships

Developer User Groups

We thought about the different types of groups might want to extend Chandler, their characteristics and brainstormed what extensibility features support certain categories of users. This was a good way in which to compare and contrast needs as well as map tenets to supporting certain groups at various levels pre and post 1.0.

Python Developers - Web 2.0

• these individuals have python expertise, some development sophistication
• high passion
• 1.0 stability might be less important
• how much data - potentially lots ie: rss
• small investment and high returns for developer usability
• this group wants to experiment and do something cool

• extensibility adding kinds
• stamping
• voip, im
• custom views
• todd's project - firefox
• headless chandler
• scripting/automation

PIM Enthusiasts

• this is are like expert users that want to do coding
• they care more about a stable app used day to day that is customized
• they want features, enhancements that support inside of chandler workflow automation
• probably new to python
• more interested in a easy ramp to extensibility
• high level of passion
• this group likely creates more data internally rather than pulling it in - more personal data
• they will likely require email support
• 1.0 stability important and performance
• possibly big investment in making it easy

• platform stuff
  • talking to the environment - mobile integration, address book, spotlight, isync services
• stamping
• customize views
• column layout
• import/export support
• scripting/automation

People who want to integrate with Chandler

• this group are interested in developing parcels to integrate with technologies they are using (ie: UCB Melville library parcel)
• some in the group likely to get some funding to write a parcel - school project
• medium investment to support them
• 1.0 stability less important for entry

• stamping
• custom views
• stamping
• custom views
• platform stuff
  • talking to the environment - mobile integration, address book, spotlight, isync services
• import/export
• scripting/automation

Web developers (headless chandler people)

• they don't care about the gui, just interested in getting at the data
• they have web programming skills
• not constrained by mimi's ui
• 1.0 stability - repository can't corrupt
• good perf required to really use
• lower investment to make it easy
• not sure about passion level

• headless
• stamping/content model
• import/export

Filemaker people (just mentioning this group but we aren't going to plan for them)

• GIM people
• less passion
• not pim domain

• content model, stamping
• import/export
• summary view customization
• user features - scripting

Calendaring sooner people

• there is another group we idenfied of people that would want to write features to help us with the calendar. It's not really in the scope of this exercise so we thought we would mention them but that's it.

Some overall themes emerging from these groupings...

• model data
• get at the data
• customize views

Tenets

We took a stab at planning out possible tenets and goals for each release based on where we are now...

0.6	0.7	0.8	0.9...	1.0	Future
- plausible python dev - plausible import/export	- usable python dev - usable web dev - api cleanup - stamping/content model - credible import/export	-customizable view -attribute editors - preferences - stamping ui			- python ecosystem: usable outside osaf - web dav usable outside osaf - integrate group usable outside osaf - platform integration usable outside osaf

Wish List

If we have a contributor from all of the different types of groups, we thought a bit about what we might want them to contribute.

1. Python Developers

• possibley support areas like voip - high usefulnees
• address book, contact management content model
• extend on amazon, flickr - ecosystem of small parcels -> social sharing - personal management of more stuff

2. PIM Geeks

• cool platform integration stuff
• mac cool platform integration
• ie: services on linux, mac address book, isync
• import/export converter - we could provide a list of file types we want people to work on with prioritization

3. Chandler Integration People

• a goal would be that some csg group could integrate to something
• ie: ucb link to melville (library catalogue)

4. Web Developer People

• some interesting web app that used data but unique usage - we can't think of an example.