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

[Philippe Bossut]

+1: I answered on the chandler-dev without realizing that Katie already 
did such a great synthetic proposal.
Cheers,
- Philippe

Katie Capps Parlante wrote:
> 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
>
> ------------------------------------------------------------------------
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
>