https://bugs.launchpad.net/ubuntu/+source/synergy/+bug/281546

The sourceforge “issue” was that you don’t find these files as part of an official source package on sourceforge (I guess because you haven’t released it yet.) It is however, possible to check out from the sourceforge SVN repository.

One more question though: I guess you drop the connection after a request is done? So no HTTP/1.1. keep alive in here? Is that right?

The usual approach with databases (and thus with common understanding of CRUD) is that all data may vary, and thus all data should be fetched each time. If this assumption holds, then aggregating a group of resources into one fetch makes a lot of sense, as it cuts down on the overhead of establishing and managing multiple connections for multiple requests.

With REST, on the other hand, the assumption is that all “get” requests may be cached. In particular, the REST clilent may already have fetched and cached some or all of the resources already. If this assumption holds, then returning a set of resource URIs and allowing the client to fetch only those which it has not already got makes a lot of sense.

Let’s consider my example of images in a web page.

The approach of returning everything every time in one request would typically result in huge and heavy web pages, each containing all the referenced images, videos, sounds, flash animations and so on. Typically the size of even one image dwarfs the few hundred (or at most few thousand) characters of the page HTML.

On the other hand, the approach of including only the URIs of the images, videos, sounds, flash animations etc. allows the client (in this case a web browser) to choose what it does. It may choose to cache images etc.; it may choose to ignore them. It may choose to fetch them all every time.

I hope we all agree that the overall web browsing experience is much smoother when a browser has already cached all the images etc, used in a page, and the same can also be true in distributed systems.

As another example, consider a search service. Such a service could return the full data of all matching resources every time, or it could return just the URIs of matching resources and allow the search client to use cached versions where possible. In common scenarios, the most popular search results will be returned lots of times, and thus can be cached, allowing the responsiveness of the system will improve over time. If all resources are returned every time, then the responsiveness can probably never improve without hardware changes.

Does that make sense?

I don’t have any hard data either, but in my experience dynamic stuff has always been easier to maintain as compared with static stuff (Ola’s post actually made me realise this).

I’m just asking myself it the better and more intelligent tooling isn’t just a necessity, a consequence of the volume of code!!!

I have generally held off from putting licensing information in the code itself - probably because I am just lazy

Rest assured that all Stringtree code is easy to use. It is dual licensed: you may choose either LGPL or Apache license (see here for details.) If you don’t like either of these licenses for some reason, let me know. I have also issued versions with other licences in the past.

I am worried that you could not download the HTTP Client code from sourceforge. What sort of problems did you face?

As for the dependencies, it seems you have got me on that one. It looks like a dependency has crept in (probably since I wrote that post back in January)

Can you quote me some licensing terms? This one looks so much more concise than apache’s http client package: 10 kB vs 500 kB speaks loud and clear

BTW: the “…with no dependencies other than the standard Java APIs…” is not 100% true: you need the URLutils class from org.stringtree.util.