Re: SDshare push

* Khalil Ahmed
> 
> Any reason why you couldn't use PuSH [1] ? Seems like it would
> separate the concerns of fragment production and fragment distribution
> nicely.

Having read through the spec once it seems to me that you could use it, provided you use an implementation that preserves the sdshare extension elements in the Atom feed. Section 7.3 in the spec is not razor-sharp on this, but does imply that implementations should preserve such elements. Whether they do in practice or not is likely to vary, I think.

However, PuSH requires you to POST to notify the hub that you've made a change. So you wind up having to do POST from the source, anyway. (IMHO this and a couple of other bits of the spec would be best either removed, or made optional.)

Also, what you get pushed to the recipient is only the Atom feed. You don't get the actual contents of the individual fragments, so those must be requested from the source, which is probably impossible. (If it's not impossible it raises the question of why you're not just using normal SDshare.)

So having thought it through I don't think this solves anything, unfortunately.

However, it does suggest a better way of doing what I called the batch proposal in my original email. Instead of coming up with yet another totally unnecessary XML format we could just post the Atom feed with the XTM in the atom:contents. That would be way simpler and more elegant, especially as anyone implementing SDshare would probably have code to read and process such a feed already.

So perhaps that's the best option, particularly as it avoids all the HTTP parameters on the endpoint that the "obvious" proposal requires.

--Lars M.
http://www.garshol.priv.no/tmphoto/
http://www.garshol.priv.no/blog/