What Alex said.
- Logarithmic is universal so that shouldn't be controversial
Lower-limit and upper-limits are already implemented. Rigid is something
very rrdtool specific so I want to punt on it at this time.
Vladimir
On Thu, 19 Jul 2012, Alex Dean wrote:
>
> On Jul 19, 2012, at 9:12 AM, Jeff Buchbinder wrote:
>
>> On Thu, Jul 19, 2012 at 8:54 AM, Jochen Hein <joc...@jochen.org> wrote:
>>> Vladimir Vuksan <vli...@veus.hr> writes:
>>>
>>>> I would define a scaling factor or some other variable. I do want to
>>>> steer away from having tool specific options unless absolutely
>>>> necessary.
>>>
>>> I agree that would be a useful goal, I just have no idea what I options
>>> I may need for my special problem [see my mail to ganglia-general].
>>>
>>> I've had a look at the other PHP-reports. A couple of them pass the
>>> option '--rigid' to rddtool. Other used options are --logarithmic and
>>> --lower-limit. I've no idea how that could be mapped into json and keep
>>> the syntax and the parsing simple.
>>
>> I'd suggest something like:
>>
>> "options": {
>> "logarithmic": true,
>> "rigid": false,
>> "lower-limit": 0
>> }
>>
>> with sensible defaults. If it's ignored by another graphing toolkit,
>> that's fine.
>
> Silently ignoring unsupported options seems like a bad choice to me, because
> it makes graph authoring & troubleshooting more difficult. If someone uses an
> unsupported option, we should blow up with an informative error message ASAP.
> Think about when you've misspelled a configuration option (in any system, not
> just gweb), and wasted a lot of time hunting for the cause of the odd results
> you see - totally frustrating, and totally preventable.
>
> More generally: The JSON format should be focused on making the simple &
> common cases easy. The format should be small, simple, & easy to use.
> Allowing lots of platform-specific options dilutes this value. The PHP route
> is still available for the non-trivial cases. If you need RRD-specific
> features, then I think PHP is the way to go.
>
> Presenting platform-specific options in a seemingly platform-agnostic way is
> worse. If we are going to support JSON options which are really RRD-specific,
> we need to make this clear.
>
> One suggestion on how to do this (which I don't like as well, but I'll
> mention it anyway): Put RRD-specific options into something like
> {"rrd-options":"--color --rigid --whatever"}. This at least gives someone
> else a clue that the JSON graph is intended only for use with RRD, rather
> than leaving it up to gweb to determine how to interpret "logarithmic" or
> "rigid" for any graphing platform we want to try supporting.
>
> alex
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Ganglia-developers mailing list
> Ganglia-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ganglia-developers
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
