[Hawkular-dev] Revisit resource naming + resource types for Alpha4

[Michael Burman]

Hi,

But this [id] or id has nothing to do with encoding. It could have just as well been 'hawkular.id' or 'id' and be an issue. This is more to do with namespacing issue than limiting what characters we could use in the metrics ids. Hawkular-Metrics still returned the exact same name as was written to it. For namespacing (if we want to have such) of the feedIds, metricIds, etc yes we should have some sort of guidelines inside Hawkular (if there's some sort of meaning in that namespace that's not passed around, but in my opinion we should always pass around the full metricId and that would be it). But to limit the id characters on components because of namespacing issue? That's not a good reason.

Not to mention the normal browser usage. If the user wants to use easily remembered ids, he should not use generated ones (who could remember uuids if they can't remember encoding rules?). If this is a question of some certain agent then it's still not a global issue. 

  - Micke

----- Original Message -----
From: "Heiko W.Rupp" <hrupp at redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
Sent: Thursday, July 30, 2015 9:03:41 PM
Subject: Re: [Hawkular-dev] Revisit resource naming + resource types for Alpha4

On 30 Jul 2015, at 18:38, Michael Burman wrote:

> Why are we fighting encoding in 2015? Mainframes had these things 

Because: 
a) the recent change of resource id format has broken code in several
places where the semantics were not really known and/or implicitly applied
Metrics are stored with a [id] while the inventory now only has id and no
longer [id]. That must not happen again

b) not all consumers/clients are machines. We need to make it easy to 
consume our services

c) the current format of specifying resource data + resource type information
may not be what we want going forward.

d) we need to ensure that if e.g. ':tag' all of a sudden gets a special 
meaning in a metric id, clients do not send that as part of a normal id,
as metrics or any other part of Hawkular may behave in ways that are
not obvious.

If we keep what we have fine. But then we need to document it and
stick to it in a consistent way all over the place, so that ids or partial
urls are/become predictable. 

_______________________________________________
hawkular-dev mailing list
hawkular-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev