DLTA extension proposal
Posted: 27 Oct 2009, 05:50
This proposal, Delta (DLTA), is a client-only extension aimed at making indexing of new content more efficient e.g. via release bots. It is advertised by broadcasting DLTA in the SU field of the INF command.
A common problem in hubs is discovery of new content. Two existing methods are:
a) for users to manually add items to a list of releases via a release bot, which then announces the latest x releases to users when they connect to the hub, and
b) for a bot to scan the file list of all connecting users and assess differences with existing known content.
This proposal would add a new file, delta.xml, to the unnamed root of a client, similar to files.xml. It would have the same structure as files.xml; however, it would only include the files which have been added to the share since the last file list refresh. An indexing bot would see the changes via the BINF SSx SFy message, and grab this file off the client. If the client supported BZIP, it would distribute this file as delta.xml.bz2.
Improvements to this idea would include a way to show files that have been removed, enabling a bot to maintain a reference counter and show the total number of sources for a file in the network when all known users are connected. The optimum method for storage and presentation to users would be via a web page, connected to a database that the bot updates.
A common problem in hubs is discovery of new content. Two existing methods are:
a) for users to manually add items to a list of releases via a release bot, which then announces the latest x releases to users when they connect to the hub, and
b) for a bot to scan the file list of all connecting users and assess differences with existing known content.
This proposal would add a new file, delta.xml, to the unnamed root of a client, similar to files.xml. It would have the same structure as files.xml; however, it would only include the files which have been added to the share since the last file list refresh. An indexing bot would see the changes via the BINF SSx SFy message, and grab this file off the client. If the client supported BZIP, it would distribute this file as delta.xml.bz2.
Improvements to this idea would include a way to show files that have been removed, enabling a bot to maintain a reference counter and show the total number of sources for a file in the network when all known users are connected. The optimum method for storage and presentation to users would be via a web page, connected to a database that the bot updates.