Hi et voilą,
LimeWire has always consistently been adding features. Prior to 2004, the underlying network was the focus of attention. Work was focused in features that weren't as visible in order to bring the network to a state that would make it very easy to add future improvements, as well as to make it work better (and with more precision). Visible features were important, but no one's going to use a client if it doesn't work... so the network was continuously improved.
Now the network has been built to work very very well. Excellent additions, such as URNs, have made features such as swarming work better and additions like partial-file sharing and TigerTree corruption validation possible. GGEP allows arbitrary information to be added to any messages, allowing LimeWires to be grouped by locale and know if any host has free slots for connecting. Dynamic Querying reduced the amount of bandwidth used by a peer and in turn reduced CPU use of LimeWire. XML (and the associated GEM extension, the precursor to GGEP) is used for sending, querying or observing metadata of a file (like ID3 information). Even things such as HTTP/1.1 support, which allows remote queuing & other key uploading features. And GUESS, the introduction of UDP into the network, led to out-of-band replies and out-of-band proxying, which cut the time spent waiting for results in half.
Features like that are very hard to develop, since there's no immediate feedback on whether or not they work.
Fortunately, the network is working well now, and it's possible to focus on LimeWire as a client. Of course, this doesn't mean that we're not continuing to improve the network. We've added "What's New" searches, work is continuing in firewall-to-firewall transfers, and we're adding improvements to the structure of the network to shape itself with stronger ultrapeers. |