a service for exposing metadata

[Myk Melez]

Not sure if this has been discussed/considered already, but I had a
thought about how to expose metadata to users.

We could have a service that metadata-handling code could register
itself with as a metadata handler. When a user loads or switches to a
page, the service would search the page for metadata with a registered
handler. If one or more handlers are registered for the metadata on the
page, the service would alert the user to the presence of the metadata
(perhaps with an icon like the feed icon) and expose UI for invoking the
handlers to do useful things with the metadata.

Handlers could register for multiple types of metadata, multiple
handlers could register for the same type of metadata, and handlers
could provide multiple commands for each type.

For example, a handler might register itself for mailto: links and
hCards, providing the commands "email everyone on this page" and "add
everyone on this page to your address book". Another handler might
register itself just for mailto: links, providing commands for emailing
each individual address.

For performance, the service itself might detect a set of popular
metadata types, like microformats, microsummaries, and mailto: links.
Handlers could register for those specific types, providing the service
with a set of commands during registration.

But for flexibility, the service would let handlers register for
metadata it doesn't already know about, in which case it would query
those handlers when the user loads or switches to a page, handing them
the document object and retrieving a set of commands from them dynamically.

Some handlers might not provide any commands, preferring to display
their own UI for users to access metadata when the handler is notified
by the service of its presence. In that case, the service would just
make handlers easier to write, factoring out code for detecting page
loads/switches and searching pages for metadata.

Seems like a service like this would make it significantly easier for
both core code and extensions to provide metadata handling while at the
same time aggregating metadata UI in a way that doesn't overwhelm the
user with individual UI elements for every component that handles
metadata in pages.

Thoughts?

-myk

[chesh2000pro]

We're right in the middle of writing an extension that handles
microformats, so despite it likely replacing a whole bunch of code that
we just got working, I think this is a great idea!

Myk Melez wrote:

> Handlers could register for multiple types of metadata, multiple
> handlers could register for the same type of metadata, and handlers
> could provide multiple commands for each type.

I think the registration part is key - ease of adding code and
flexibility to handle a diverse range of protocols and metadata types
will be really important to getting this adopted. Registering for the
presence of links using a specific protocol is much simpler than
defining a complicated metadata markup strategy, so I think the idea of
providing support for "simple" notifications (e.g.: "mailto:" links,
"vcard" classes) accomplishes part of the problem and the ability to
add a callback to do your own detection handles the latter.

> For example, a handler might register itself for mailto: links and
> hCards, providing the commands "email everyone on this page" and "add
> everyone on this page to your address book". Another handler might
> register itself just for mailto: links, providing commands for emailing
> each individual address.

I'd suggest a few places in the UI that the handler could be added -
our in-progress extension adds an icon next to the Feed icon in the
address bar and a graphical element inserted on pages at the point
where it finds a microformat to allow the user to interact with it
directly. We could also do the context menu for links.

> Seems like a service like this would make it significantly easier for
> both core code and extensions to provide metadata handling while at the
> same time aggregating metadata UI in a way that doesn't overwhelm the
> user with individual UI elements for every component that handles
> metadata in pages.

It definitely could, though the fact that my code could react in any
way I'd like once it was called means that I could still add UI
elements if I wanted to. I guess we could encourage developers to focus
on a few core widgets and suggest they use those without closing the
door to using other ones. This would have made developing our widget a
whole bunch easier as we could have just focused on the core UI pieces
and actions for handling data rather than having to start from scratch
with detection and widgets for initiating actions.

Thanks for the concept Myk!

Jay Goldman
Radiant Core, Inc.
We build websites that build your business™.