> Okay, this is just an idea ... Why not support a real database then to store > the data (read the first * below before you react)?
You could use JDBC and a database if you wanted to. I personally hate it when software uses a database when it's not necessary. You need to set up a database (which often requires root access) and that's a pain. For high traffic nodes it might be a good idea. Relational databases are generally optimized for do fast lookups on relationships. What we want to do really is just find the file based on a simple hash table and then transfer it as fast as possible. I think an in-memory hashtable pointing to files on the filesystem (possibly buffered in memory if there is a lot of RAM) works fine for this for many, many files. All of this superoptimization for high-traffic, high-end nodes is not really relevant to the reference implementation, which needs to be optimized more towards featurefulness and standards compliance. Speed junkies are going to want a C node instead anyway so they can squeeze out some CPU cycles. So I would say that while there might be an audience for this sort of thing, it's probably pretty small and not appropriate for inclusion in the reference implementation. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
