API wishlist :)

[jallspaw]

Hey all!

Here's some of my wishlist for a swivel API:

- return rows for a given graph ID
- return columns for a given graph ID
- return graph IDs that is using a particular dataset (related graphs)
- return graph IDs with a given tag
- return graph IDs with given text found in title/description
- return graph type (bar, pie, etc.) for given graph ID
- post to blog
- return blog URLs for a given graph

crazy ? good ? :)
john

[huned]

hey, john, thanks for the feedback! we've been thinking along those
same lines, mostly.

one particular discussion we had here was whether or not to return csv
(as xml cdata) or just plain xml for the data. that incited a fun
little internal flame-war :)

glad to hear your thoughts!

huned
at swivel

[jallspaw]

Ah. well the propeller-heads in our office think that it should just
be returned as plain xml. :)

-j

[jallspaw]

quoting a friend:

"as in: <field_name>field_value</field_name><field_name2>value</
field_name2> etc
....which should be doable, because presumably they've already parsed
the csv once
but it *might* be more useful in the context of an excel app driven
by an api (do such things exist) do do <somedata:csv><[[CDATA ...... </
somedata:csv>

so that the consumer doesn't have to re-transform
so: both!" :)

[huned]

j - that is excellent! we also concluded that we should support
several formats, but for now probably just csv and xml.

the biggest problem i see with representing a data table in xml is
that it's just verbose. re-outputting the column name for every row
when i have a 1000 rows gives me 1000 instances of column names in xml
tags. i only need the column name information once, after which i
know the table structure. so i discover the column names from the
first row, and the other 999 outputted instances of each column name
don't give me any additional information. that made me a bit sad.
the implementation i've currently chosen outputs the column names just
once and then uses lightweight xml to represent each row, and each
value within each row.

but, yeah, csv is also cool -- i have a hunch that many apps that want
to consume data are already set up to parse csv. in that case,
providing those apps with csvs from swivel is the thing to do.

so, yeah, both :)

[huned]

also, thanks to your friend for the feedback!

On Mar 6, 10:34 am, "jallspaw" <alls...@gmail.com> wrote:

[Dmitry Dimov]

Huned, what you ended up doing is similar to what I saw in Google Adwords xml format, there's a header section listing columns, and then a swath of xml content that follows the column order in the header but doesn't repeat the column names. This also reminds me of a lot of stats and research data I see out there, with one file describing the columns, and the other is just raw "headless" data.

[Jim Giza]

> Ah. well the propeller-heads in our office think that it should just
> be returned as plain xml. :)

Why limit out of the gate? There're millions of apps ready to slurp
comma or tab separated.