Changing SEGA's groups
Posted: 15 Aug 2012, 18:03
SEGA (grouping search extensions): If a file extension was a) to be added that isn't in the current spec (say, imagine "mp3" came out tomorrow) or b) to be removed from the current spec (imagine we want to throw out "mp3" because X).
1) The extension could simply be added (always) as an additional EX field (so we always lose X bytes when searching). I.e., we say we don't change the current spec.
2) Change the spec to a new version (say, SEG2 for SEGA 2) and with the differences managed.
3) Change the spec of the existing lists but don't change the FCC; this will mean that older implementations will simply not respond in a) and they will respond with results you don't want (false positives).
4) Create a new type list (i.e., take a new value and set your new list there or your list would constitute of only one value [wasteful]); older implementations will not respond since they don't know the new list
5) Introduce a mechanism to manage the actual values remotely. I.e., we introduce new parameters, FCC, a command etc that will allow us to specify what each list is made up of. It would also be possible to manage this straight up in SCH, by for instance sending a new parameter "remember the additions and removals I am making" or something similar. With any type of remote management, you have to then in each client keep a record of everyone else's list, which is obviously costly. While this management is the most flexible one, it comes with a protocol cost, obviously. To manage the protocol cost, the hub could (say, when logging in) decide what the list is (for each respective known type); that means you decide on a per hub basic what each list is, and you decrease memory and protocol cost. (Let's not discuss B-type forwarding abuse.)
I haven't thought this through much, but I thought a discussion would be in order.
1) The extension could simply be added (always) as an additional EX field (so we always lose X bytes when searching). I.e., we say we don't change the current spec.
2) Change the spec to a new version (say, SEG2 for SEGA 2) and with the differences managed.
3) Change the spec of the existing lists but don't change the FCC; this will mean that older implementations will simply not respond in a) and they will respond with results you don't want (false positives).
4) Create a new type list (i.e., take a new value and set your new list there or your list would constitute of only one value [wasteful]); older implementations will not respond since they don't know the new list
5) Introduce a mechanism to manage the actual values remotely. I.e., we introduce new parameters, FCC, a command etc that will allow us to specify what each list is made up of. It would also be possible to manage this straight up in SCH, by for instance sending a new parameter "remember the additions and removals I am making" or something similar. With any type of remote management, you have to then in each client keep a record of everyone else's list, which is obviously costly. While this management is the most flexible one, it comes with a protocol cost, obviously. To manage the protocol cost, the hub could (say, when logging in) decide what the list is (for each respective known type); that means you decide on a per hub basic what each list is, and you decrease memory and protocol cost. (Let's not discuss B-type forwarding abuse.)
I haven't thought this through much, but I thought a discussion would be in order.