Subject: [forces] item #15: New Table operations

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 16 Jan 2013 10:14:58 -0500

Folks,

This will be the last work item i post. If you think i missed something that
you wanted and REALLY REALLY MUST have it mentioned, we can make
an exception.

What it is
----------

A couple of new table operations.

1) For the sake of illustration: consider a million table entries
at an FE, and a ForCES application is only interested in querying 300 table
rows residing in said table; at the moment this would require either
300 ForCES messages or a batch message with 300 subpaths indicating
row indices as path endpoints. What is being proposed is a small extension
not unlike the KEY path selector to specify table ranges.

2) When a ForCES application is interested in adding a table row
entry, the path must constitute the index as well. In most cases the
use case is for adding a new table entry and the "next" table index
information is supposed to be known by the CE; however, there are use
cases where it is not known or not optimal to know. ForCES architecture
provides facilities for querying the properties of a table residing at
the FE to find the next usable index, however that requires a round trip
to retrieve. The proposal here is to add an optional flag to the path
selector for tables which tells the FE to use the next available index.

Why it is needed
----------------

Implementation/operational experience has demonstrated
range query for tables and table appends (table row insertions
without specifying table indices) as useful optimization operations.

Please respond whether you:
a) are interested in doing the work
b) will review the work
c) find the work interesting and it should be done in the WG
d) do not think we should do this work