Draft 0.1: inviting your feedback

[Ka-Ping Yee]

Hello,

My apologies for the long silence.  I have posted a first draft of the Tablecast protocol specification here, ready for your review:

    http://tablecast.org/draft-0.1

I'd very much appreciate your feedback and suggestions for improvement.  It is still a working draft and I'd be glad to hear whether you find its requirements feasible to implement, how it would fit with your application and use cases, and whether there are ways it could be made easier to understand.

Thanks!

—Ping

Google Crisis Response

[Patrick Dwyer]

This looks like a fantastic draft spec for Tablecasting! Still reading
through the last few sections, but wanted to post a few questions as I
found them:

This could be a semantic/application specific question, but how would
a tablecast feed differentiate specific tables within a dataset? For
instance, in a data set containing multiple relational tables, how
would we specify Table A versus Table B? I can see a few
possibilities:

1. Different tablecast feed per table in a dataset
2. tc:edit#record attributes include the table and record
3. Separate tc:edit attribute to specify a table

This also brings up the question of grouping edits together. While
avoiding the overhead and nuisance of foreign keys/consistency/
transactions, it would be convenient to be able to group a set of
edits across multiple tables in a dataset into the same tablecast
feed; this would leave the integration of the edits, and eventual
consistency up to the application, but would make it possible to have
"soft" transactions.

[Ka-Ping Yee]

Hi Patrick,

Thanks for the comments!

On Wed, Dec 1, 2010 at 13:24, Patrick Dwyer <patrickn...@gmail.com> wrote:

This could be a semantic/application specific question, but how would
a tablecast feed differentiate specific tables within a dataset? For
instance, in a data set containing multiple relational tables, how
would we specify Table A versus Table B? I can see a few
possibilities:

1. Different tablecast feed per table in a dataset
2. tc:edit#record attributes include the table and record
3. Separate tc:edit attribute to specify a table

I think the simplest thing is to have each feed represent one table, which fits naturally with the ability to select which feeds you want to subscribe to.

Draft 0.1 uses the word "dataset" to mean a table, but perhaps that is confusing since that sometimes means multiple tables.  Would the spec be clearer if it used "data table" instead of "dataset"?

This also brings up the question of grouping edits together. While
avoiding the overhead and nuisance of foreign keys/consistency/
transactions, it would be convenient to be able to group a set of
edits across multiple tables in a dataset into the same tablecast
feed; this would leave the integration of the edits, and eventual
consistency up to the application, but would make it possible to have
"soft" transactions.

Interesting.  I'm inclined to keep the first version of the spec as lean as possible.  Grouping edits doesn't sound essential to me, but if I'm underestimating its value, perhaps I'll understand it better with a specific example?

—Ping