Firefox plugin: Difference between revisions

From Project VRM
Jump to navigation Jump to search
mNo edit summary
m (typos)
Line 5: Line 5:
Vendors may tag pages with Technorati-style information: href="locationOfVendorAgentOrDataStore" rel="VRM"
Vendors may tag pages with Technorati-style information: href="locationOfVendorAgentOrDataStore" rel="VRM"


Seekers install browser plugin and configure with basic information (private identity, location of public identity, default behaviors).  When the seeker visits a page that's tagged with VRM information, that information is either automatically or manually (user option) to their data store.  RFP creation can then be handled locally, from within the browser (online or offline), and the RFPs passed to vendors when a network connection becomes available.  Plugin could also periodically poll known vendor data stores for offers that match the user's outstanding RFPs.
Seekers install browser plugin and configure with basic information (private identity, location of public identity, public RFP store location, default behaviors, etc.).  When the seeker visits a page that's tagged with VRM information, that information is either automatically or manually (user option) added to their local data store.   


Could work bi-directionally, as well, offering user the option to submit their own data store information (if they have a public location for RFPs, which becomes optional in this model) to individual vendors, who then periodically poll the user's public RFP.
RFP creation can then be handled locally, from within the browser (online or offline), and the RFPs passed to vendors when a network connection becomes available.  Plugin could also periodically poll known vendor data stores for offers that match the user's outstanding RFPs; this model also means that seekers can set up an entirely private, passive monitoring system as "watch these vendors for offers that meet these criteria, but don't publish the RFP to my public space.


This approach also fits with third-party participation, as third parties can act as aggregators:  visit aggregator site and get data store information for 10, 100, or 1000 vendors all at once if desired.  Conversely, user could submit their public RFP location to 10,100, or 1000 vendors all at once.
Could work bi-directionally, as well, offering user the option to submit their own data store information (if they have a public location for RFPs, which becomes optional in this model) to individual vendors, who then periodically poll the user's public RFP store.
 
This approach also fits well with third-party participation, as third parties can act as aggregators:  visit a third-party aggregator site and get offer data store information for 10, 100, or 1000 vendors all at once if desired.  Conversely, user could submit their public RFP location to 10,100, or 1000 vendors all at once.
 
Interestingly, this model does seem to jive well with Doc's ca. 2004 "actively but selectively notify vendors" requirement from the minidisc recorder post.


REF: attentiontrust.org/root.net
REF: attentiontrust.org/root.net

Revision as of 13:56, 19 December 2006

Seeker Toolbox as Firefox Plugin

Not ideal, but interesting, as it's an implementation that reduces the dependency on crawlers (which are complicated from a totally distributed seeker perspective) and/or third party warehouses of pointers to seeker and vendor data store locations.

Vendors may tag pages with Technorati-style information: href="locationOfVendorAgentOrDataStore" rel="VRM"

Seekers install browser plugin and configure with basic information (private identity, location of public identity, public RFP store location, default behaviors, etc.). When the seeker visits a page that's tagged with VRM information, that information is either automatically or manually (user option) added to their local data store.

RFP creation can then be handled locally, from within the browser (online or offline), and the RFPs passed to vendors when a network connection becomes available. Plugin could also periodically poll known vendor data stores for offers that match the user's outstanding RFPs; this model also means that seekers can set up an entirely private, passive monitoring system as "watch these vendors for offers that meet these criteria, but don't publish the RFP to my public space."

Could work bi-directionally, as well, offering user the option to submit their own data store information (if they have a public location for RFPs, which becomes optional in this model) to individual vendors, who then periodically poll the user's public RFP store.

This approach also fits well with third-party participation, as third parties can act as aggregators: visit a third-party aggregator site and get offer data store information for 10, 100, or 1000 vendors all at once if desired. Conversely, user could submit their public RFP location to 10,100, or 1000 vendors all at once.

Interestingly, this model does seem to jive well with Doc's ca. 2004 "actively but selectively notify vendors" requirement from the minidisc recorder post.

REF: attentiontrust.org/root.net