[I'm going to prefix this with - "this is all in my opinion" - if I'm the sole voice in the wilderness on this, I'll shut up.] Banning characters from resource ID strings that are not valid in URIs is essentially forcing an unnatural limitation on the feeds. First, feeds don't care that these resource IDs might end up on URLs. But they do care to use a string that identifies a resource (which may contain URI-restricted chars). Second, hawkular server should not dictate anything about resource IDs that feeds want to set. It should be the feeds that tell the server what they want the IDs to be and the server just uses them. There are going to be third party feeds that will want to set their own IDs and I think you are just going to have to eventually solve this problem anyway (the whole goal of the "feed" system was to make writing feeds the easiest as possible - dictating to the feed authors how they must design their IDs goes against that - IDs should be strings, that's all the restriction we should place on them). Next you are going to want to put the limitation that resource IDs must be normalized and cannot have parent IDs in them :) but rather IDs should only contain the last address path segment and the resource ancestry should have the rest of the ID parts; thus causing the feeds to no longer have a fully addressable resource ID easy at hand but instead feeds would now be required to do the extra steps of either calculating full addresses for resources by crawling the ancestor tree and performing string manipulation or be forced to add another piece of redundant data to hold a pre-calculated full address. In other words, making the life of the feed author harder. I say err on the side of cleaner, easier to write and maintain code for the feed author, which will also tend to make it more efficient at runtime (since there will be no need for extra string manipulation). And it will make less hoops that community-developed feed developers will have to jump through. In other words, let us do some up-front extra work and free the feed developer from having to do extra work to encode IDs so they are acceptable to Hawkular. Is this really just so we can support pretty REST URLs (which I assume the customer never sees, right?) Are there other reasons for wanting this restriction? Because it really shouldn't be a problem to allow encoded REST URLs. ----- Original Message -----

----- Original Message ----- Also part of the problem is that even if everything we write and control ourselves is properly encoding the URL, it doesn't mean that this will properly work out on an actual network somewhere. There are other intermediary server which may control and route connections, and these servers tend to really not like certain elements within a URL, even if they are properly encode. We have already ran into a bunch of issues with this already where something else doesn't like it and either blocks or mangles the URL before sending it off to our components. Which sucks, because then our stuff wont work properly due to bugs in completely separate servers. So far we have come up work arounds (sort of, for one component it ended up that we just couldn't use it), but I have a feeling eventually we may have to add an option to base58 encode the metric id in the url