[Design] [Proposal] Removing plugins and what else for Preview?

[Katie Capps Parlante]

We've been discussing how to handle plugins on the chandler-dev list, 
and I think we've hit on some topics that really belong on design, so 
moving the conversation.

For background on the conversation that followed Heikki's initial 
message, check out the dev-list thread:
http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/007608.html

Ok, new proposal...

+ Do not remove plugins from end-user release
    - have them be "disabled" by default, not loaded
    - leave the projects/ and samples/ directories in the distribution
    - have a menu item that "turns on" or "enables" plugins

(Presumably in the future we'll have a better ui to do this plugin by 
plugin, perhaps from a preferences panel, but just do something very 
basic for Preview)

+ Create a "test" plugin and move test code to this plugin
    - e.g. "generate items"

+ Remove the "Test" menu altogether, and create a "Tools" menu which is 
available in all releases.
    - "test" plugin can insert some menu items into "Tools"
    - "check repository" and similar tools can remain available in 
"Tools" by default, even in end-user release

+ Rename "Experimental" to the shorter "Demo"
    - plugins like "amazon" and "flickr" can insert menus here while 
they are still of "demo" quality

Arguments in favor of the proposal:
- the current plugins do not dramatically impact the download size, so 
we're not losing much here
- end-user awareness of plugins is a GoodThing(tm)
- some potential developers will grab the end-user release -- 
lightweight plugin development should be doable with the end-user 
release (long term goal); basically we don't want to *hide* the idea of 
plugins from people (developers or users), we want to do the opposite
- the main advantage of not including the plugins was to not make a 
commitment to a high quality level in the "demo" plugins -- we satisfy 
this goal if they are disabled by default

Cheers,
Katie

Heikki Toivonen wrote:
> Katie mentioned that we plan to remove plugins from Preview. This
> prompted me to get a clarification of what exactly do we want to remove
> in Preview.
> 
> I'd like to trim the end-user release to NOT include:
> 
> projects/ directory (i.e. plugins)
> tools/ directory (i.e. functional and performance tests)
> *tests* directories (i.e. unit tests)
> samples/ directory
> all files not needed to run Chandler or Python itself under release/
> directory (i.e. remove any scripts and utility executables still left
> there - I have proposed to make a separate zip download for people who
> want these)
> Experimental menu
> Test menu (we'd probably want to move some more of these items to the
> remaining menus)
> 
> I'd leave developer release as is.
> 
> Note that this would mean that localizers would need to get the
> developer build unless we made a localizer's zip that could be unpacked
> over the end-user release.
> 
> Pros:
> * Smaller downloads
> * Smaller disk footprint
> * Slightly smaller memory footprint
> * Slightly better performance
> * A little cleaner UI
> 
> Cons:
> * Dealing with the confusion of different files in end-user and
> developer releases
> * Need to make some downloadable packages for tools
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev