[Having a mime-type registry]
I think that's a good idea. Note that this generaly gives you a very
small protocol - "open the application on this content". This would be
useful both from within a web browser (so when you see a link to a cs,
it can open a package browser) and within a mail (for attachments). But
it doesn't solve the FileList problem (no mime types given).

[Creating one general solution to pluggability]
Seems premature to me. As Andreas says, different points of entry
require different protocols anyway. 

Though maybe not - I heard a lecture about the Eclipse Java editor/IDE,
and they define a set number of hooks, where extensions can register
themselves. The registration, instead of being by code, as we use, is
done declaratively by providing an XML description of the service (I'm a
type inference engine, I have menu item A that should go under X and a
display pane B that should...).

Anyway, for now, as we find ourselves repeating the same plugging
patterns, we'll probably generalize. For example, SteveB has posted a
package that adds a pluggable look menu. That should be brought into the
image, and maybe a more general mechanism needs to be added for
pluggable menu items, that includes both that and the open menu.

Daniel

Avi Bryant <avi at beta4.com> wrote:
> 
> On Sat, 29 Mar 2003, Adam Spitz wrote:
> 
> > For now I've done something similar to what Daniel did with Celeste: I
> > left a little tiny class called WebBrowser in the image, which allows
> > web browser packages to register themselves with it. So if you're
> > writing some unrelated package and you want to be able to open a web
> > browser, you can write "WebBrowser preferred" instead of "Scamper", and
> > if there's no web browser registered you'll get a little message saying
> > so.
> 
> If we're going to keep doing this, we should maybe generalize it further,
> so that you would have something like
> 
> Service named: #webBrowser
> Service named: #mailReader
> 
> and then the installers could do
> 
> Service registerClass: Scamper as: #webBrowser
> 
> Thinking further, it seems like this and the registering file list are
> both just instances of the kind of mime-type handler registries that most
> web browsers and file managers have these days.  Maybe that's the
> direction we want to go?
> 
> Avi