You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently MetadataService validates the metadata against both metainfo.yml and infodict.yml. The former is supposed to be the schema of .torrent files, and the latter -- of the info dictionary (which is also the format of peer-exchanged metadata per BEP-9 Extension for Peers to Send Metadata Files). The reason for this is that IMetadataService interface is generic, so there's no way to know inside of the implementation, which of the two formats the actual metadata has.
I noticed that literally a few lines later we already work around this issue, in order to know which variant of TorrentSource to create, by checking for presence of info property (see comment on this below*). We might move the validations into the IF clause:
BEMapmetadata = parser.readMap();
Map<String, BEObject<?>> root = metadata.getValue();
BEMapinfoDictionary;
TorrentSourcesource;
if (root.containsKey(INFOMAP_KEY)) {
// standard BEP-3 formatValidationResultvalidationResult = torrentModel.validate(metadata);
if (!validationResult.isSuccess()) {
thrownewBtException("Validation failed for torrent metainfo: "
+ Arrays.toString(validationResult.getMessages().toArray());
}
infoDictionary = (BEMap) root.get(INFOMAP_KEY);
source = newTorrentSource() {...};
} else {
// BEP-9 exchanged metadata (just the info dictionary)ValidationResultvalidationResult = infodictModel.validate(metadata);
if (!validationResult.isSuccess()) {
thrownewBtException("Validation failed for info dictionary: "
+ Arrays.toString(validationResult.getMessages().toArray());
}
infoDictionary = metadata;
source = newTorrentSource() {...};
}
By doing so we will make sure that the user does not see irrelevant validation errors.
--
* This is not a very good approach, because if the info dictionary contained an info property, it would result in a confusion. OTOH, this will not happen as long as the info dictionary strictly adheres to the format outlined in BEP-3.
The text was updated successfully, but these errors were encountered:
Currently
MetadataService
validates the metadata against bothmetainfo.yml
andinfodict.yml
. The former is supposed to be the schema of.torrent
files, and the latter -- of the info dictionary (which is also the format of peer-exchanged metadata per BEP-9 Extension for Peers to Send Metadata Files). The reason for this is thatIMetadataService
interface is generic, so there's no way to know inside of the implementation, which of the two formats the actual metadata has.I noticed that literally a few lines later we already work around this issue, in order to know which variant of TorrentSource to create, by checking for presence of
info
property (see comment on this below*). We might move the validations into the IF clause:By doing so we will make sure that the user does not see irrelevant validation errors.
--
* This is not a very good approach, because if the info dictionary contained an
info
property, it would result in a confusion. OTOH, this will not happen as long as the info dictionary strictly adheres to the format outlined in BEP-3.The text was updated successfully, but these errors were encountered: