On 06/06/2010 10:27 AM, Ravi Pinjala wrote:
This looks interesting! Here are some thoughts I had while reading through it:
* It would be nice if there was a Content-Type required (or at least
encouraged) for topics, so that hubs wouldn't have to infer the
content type from the content. This would make it more efficient for a
single hub to support both Atom/RSS and JSON streams.
Agreed.
In light of Monica's proposal for generic content-types, it seems that
the specific message format proposed in my spec should have its own
specialized MIME type so that it doesn't overlap with the use of the
general type application/json, which might be used for JSON documents
that do not conform to the specific structure I called out in the
specification.
Since this specification defines two differing JSON object structures it
should probably define a MIME type for each.
I imagine then that there would be several MIME types which are
considered "special" to a hubbub hub, where piecemeal delivery is
possible, and then any others would be treated as opaque blobs as
described in Monica's proposal.
* What's the relation between the Discovery Document and the
Notification Message? It seems like it's two different names for what
amounts to the same format, that's just used differently between the
publisher->hub and the hub->subscriber.
They started off as the same thing but with the former having a "hub"
property. However, when I came to accommodate combining notifications
for multiple topics into a single notification I added an additional
level of indirection (the "notification packet") to have somewhere to
put the topic URL.
So a discovery document looks like this:
{
"hubs": [ "https://example.com/hub"; ],
"items": [
{
"arbitraryPayload": 1
}
]
}
while the notification message looks like this:
{
"items": [
{
"topic": "http://example.com/topic";,
"payload": {
"arbitraryPayload": 1
},
}
]
}
This minor difference is slightly annoying, but it seemed more desirable
to me that requiring the discovery document to redundantly re-state the
topic URL for each payload.
* In section 5, it says "Implementations MUST ignore properties that
they do not understand." Do you mean ignore and drop these properties,
or ignore and preserve? I feel like it could be read either way.
I suppose I mean "drop"; I'm not sure what it would mean to "preserve"
in this context, since the hub is not ever required to reproduce the
root object of either document, so it is not apparent externally whether
the hub dropped or preserved the properties.
* Section 6: "This section defines a message format that can be used
by the publisher..."<- should that be subscriber, or am I misreading
this entirely?
Yes, I believe I meant to say "subscriber" here, or alternatively I may
have originally completed the sentence as "convey the locations". Either
way it doesn't make sense as currently written. Thanks.
* Section 7 doesn't feel right to me. What you want is an equivalence
comparison for JSON objects; what you're describing is a specific
optimized algorithm for one. This is just an implementation detail for
the hub; it doesn't need to be part of the spec.
Is there a standard comparison I could reference? I want publishers to
be able to rely on a particular definition of "the same" vs. "different"
so that they don't get differing behavior for the same documents between
hubs.
Accidental differences I was anticipating were:
* Failure to handle non-ASCII characters correctly due to differing
encodings between the stored representation and the new representation.
* Some languages failing to distinguish between 1 and true, 0 and
false, "" and false, etc.
* Failures when the publisher changes whitespace usage and the hub
failed to normalize whitespace.
* What are the pros and cons of this proposal, versus wrapping JSON
objects in an Atom feed?
I would consider it a failure if an implementation of this protocol had
to have both an Atom parser and a JSON parser around in order to
operate. The goal is a natural representation of JSON-native data;
encapsulating JSON into XML is not "natural".
Of course, the con is that hubs must have support for this additional
format, but since PubSubHubbub assumes a coupling between publisher and
hub this is not a big deal since the publisher will use a hub that
supports the serialization formats it uses.
Thanks for the feedback! Hopefully I'll be able to produce another draft
later this week incorporating all of this.
