[core] Pub-Sub Issues/Discussions

[Jim Schaad <[e-mail]>]

So I found the interim call today very useful in terms of trying to get some
progress on how to implement a Pub-Sub server.  I am going to recap what I
heard and add some items that were not said but I think were implied from
the discussions for general review.

1.  Vocabulary and default values:
The set of items in proposal.txt is a reasonable starting place but is going
to get changed in many ways going forward, not the least in the URI being
used.

Content Type:  If not provided by the creator defaults to the first content
type published to the topic.  One implication of this is that all items
published to the server are required to have a content type.

Lifetime:  There are two separate lifetime values, one for the topic and one
for the data.  The default for the topic is infinite, but a server could be
configured to have a lower value to prevent building up crud.  The default
for data is infinite and should not be configured by the server only the
topic creator.  A topic expiring will automatically garbage collect the data
object as well.

Vocabulary will need to provide some behavior questions on read/write and
filter:   I expect there are write-once items (ct, initial value), items
which are never read (initial value)

2.  CoRAL order implications:  The gist of the conversation is that for some
applications the order of items in the CoRAL serialization is significant,
but for other applications the order is not going to be of significance.
My guess is that for pub-sub the order is not significant and will start
that way.  The order however might be significant for some of the data that
is attached and attributed to the topic creator.  This leads to a CoRAL
discussion topic about how to put third party statements into a CoRAL
document in such a way as to make sure that the third party is identified as
responsible for the statements and not the provider of the CoRAL document.

3.  Hierarchy of topics: This really needs to be done, but nobody really
understands the implications of what should be done.  As an example, can you
"subscribe to a root resource" and get any events for all changes in the
child nodes as well as the root node.  If the answer is yes, then there are
questions about how this is presented to the subscriber to ensure that this
works well.  The ability to do filtering, condition/event triggers and so
forth makes this even more complicated.

4.  Currently the concept of creating a topic on publish of the data is no
longer viable.  There will be a method for providing an initial data item to
be published when the topic is created, along with the ability to do a
tombstone publication.  

Jim