diff options
Diffstat (limited to 'RATIONALE')
-rw-r--r-- | RATIONALE | 36 |
1 files changed, 28 insertions, 8 deletions
@@ -241,6 +241,8 @@ PROBLEM GROUP 6 (FS-APIs): | |||
241 | saves to disk on shutdown) | 241 | saves to disk on shutdown) |
242 | * FILENAME metadata is killed by ECRS/FSUI to avoid | 242 | * FILENAME metadata is killed by ECRS/FSUI to avoid |
243 | exposing HOME, but what if the user set it manually? | 243 | exposing HOME, but what if the user set it manually? |
244 | * The DHT was a generic data structure with no | ||
245 | support for ECRS-style block validation | ||
244 | 246 | ||
245 | SOLUTION: | 247 | SOLUTION: |
246 | * Eliminate threads from FS-APIs | 248 | * Eliminate threads from FS-APIs |
@@ -249,6 +251,10 @@ SOLUTION: | |||
249 | * Have API to manipulate sharing tree before | 251 | * Have API to manipulate sharing tree before |
250 | upload; have auto-construction modify FILENAME | 252 | upload; have auto-construction modify FILENAME |
251 | but allow user-modifications afterwards | 253 | but allow user-modifications afterwards |
254 | * DHT API was extended with a BLOCK API for content | ||
255 | validation by block type; validators for FS and | ||
256 | DHT block types were written; BLOCK API is also | ||
257 | used by gap routing code. | ||
252 | 258 | ||
253 | 259 | ||
254 | PROBLEM GROUP 7 (User experience): | 260 | PROBLEM GROUP 7 (User experience): |
@@ -258,20 +264,34 @@ PROBLEM GROUP 7 (User experience): | |||
258 | creates thousands of search results for the mime-type keyword | 264 | creates thousands of search results for the mime-type keyword |
259 | (problem with DB performance, network transmission, caching, | 265 | (problem with DB performance, network transmission, caching, |
260 | end-user display, etc.) | 266 | end-user display, etc.) |
267 | * Users that wanted to share important content had no way to | ||
268 | tell the system to replicate it more; replication was also | ||
269 | inefficient (this desired feature was sometimes called | ||
270 | "power" publishing or content pushing) | ||
261 | 271 | ||
262 | SOLUTION (draft, not done yet, details missing...): | 272 | SOLUTION: |
263 | * Canonicalize keywords (see suggestion on mailinglist end of | 273 | * Have option to canonicalize keywords (see suggestion on mailinglist end of |
264 | June 2009: keep consonants and sort those alphabetically); | 274 | June 2009: keep consonants and sort those alphabetically); not |
265 | while I think we must have an option to disable this feature | 275 | fully implemented yet |
266 | (for more private sharing), I do think it would make a reasonable | ||
267 | default | ||
268 | * When sharing directories, extract keywords first and then | 276 | * When sharing directories, extract keywords first and then |
269 | push keywords that are common in all files up to the | 277 | push keywords that are common in all files up to the |
270 | directory level; when processing an AND-ed query and a directory | 278 | directory level; when processing an AND-ed query and a directory |
271 | is found to match the result, do an inspection on the metadata | 279 | is found to match the result, do an inspection on the metadata |
272 | of the files in the directory to possibly produce further results | 280 | of the files in the directory to possibly produce further results |
273 | (requires downloading of the directory in the background) | 281 | (requires downloading of the directory in the background); |
274 | 282 | needs more testing | |
283 | * A desired replication level can now be specified and is tracked | ||
284 | in the datastore; migration prefers content with a high | ||
285 | replication level (which decreases as replicase are created) | ||
286 | => datastore format changed; we also took out a size field | ||
287 | that was redundant, so the overall overhead remains the same | ||
288 | * Peers with a full disk (or disabled migration) can now notify | ||
289 | other peers that they are not interested in migration right | ||
290 | now; as a result, less bandwidth is wasted pushing content | ||
291 | to these peers (and replication counters are not generally | ||
292 | decreased based on copies that are just discarded; naturally, | ||
293 | there is still no guarantee that the replicas will stay | ||
294 | available) | ||
275 | 295 | ||
276 | 296 | ||
277 | 297 | ||