On Thu, May 02, 2013 at 10:50:25AM -0700, Chiradeep Vittal wrote: > > > On 5/2/13 6:24 AM, "Chip Childers" <chip.child...@sungard.com> wrote: > > >On Thu, May 02, 2013 at 12:40:45PM +0530, Abhinandan Prateek wrote: > >> > >> The tags are name-value pairs basically meant to label resources by a > >>user. > >> The purpose of the current API is to add useful meta information to > >> resources so that they can be meaningfully controlled by external tools. > >> > >> The current implementation of meta info API may look similar to tags > >>with > >> possible edition of a "system" or a "user" qualifier/flag in order to > >> control visibility. > >> > >> But it is not so. Tags by definition are name value pairs where both > >>name > >> and value is a string. If we try to set the meta data information in the > >> tags we are severely restricting the type of meta information that can > >>be > >> contained in the tags. For example if the "data-type" information is > >> required in this meta-data we will end up tweaking the tag system to > >>serve > >> some purpose that it is not meant for. > >> > >> I strongly suggest that we do not try to contain the meta information > >>in a > >> restricted framework provided by tags. > >> > >> -abhi > > > >I don't understand this argument. Most primary data types have string > >representations, right? (ref: JSON) > > > >Are you talking about complex types? Or things like integers, long, > >datetime, etc...? > > I didn't understand it either. > Perhaps the issue is whether this meta-data is available to the end-user > or not? At least, tags are visible to the end-user. Is it the intention > that this 3rd party service do its magic in cahoots with the admin? > >
I'd be OK if we were talking about an ACL for that, but I can see plenty of reasons for a user to want meta-data about their instances.