However, the format LIMITS the data. YAML can describe more things than JSON, JSON can describe more things than CSV and SQLite and friends.
If you go with arbitrary formats though, this does seem to lead you towards a solution that involves tabular data rather than tree data, so that you have the SQLite and CSV options available. Adam K On Thu, Jan 7, 2010 at 12:13 AM, brian d foy <brian.d....@gmail.com> wrote: > We don't have to put the data in any particular format. There's no need > to choose any format. We can have them all. With whatever I do, I want > to support everything. > > If the CPAN client says it can handle JSON, it can download JSON. If it > wants YAML, it can download YAML. If it needs just text, that's fine > too. SQLite? Excel? XML? Oracle dump file? ROT13 ASCII art? Bikeshed > Standard Protocol Specification Hex Color Expanded Multidimensional > Language Storage Format Second Edition? No problem. > > At the application level, there will be something that says "Give me > what I need for module Foo". Beyond that, it's just data connectors. If > we do it right, almost none of the code should care or know the format. > > On the server side, we can have as many formats as Andreas cares to > make for us. After all, it's his database that is the actual source of > the data. >
