Re: SDshare push

Hi Lars,

[...]
>  (2) Semantics are different, in that APP expects a new fragment
>      to be created, but that's not what we are doing at all.

Can you explain that point? I don't understand what you mean with "APP
expects a new fragment to be created".

>  (3) None of what APP provides actually seems to be useful for our
>      use case. Using APP doesn't make the SDshare push spec any
>      simpler; in fact, quite the contrary.

APP provides a service discovery mechanism (which could be optional
for SDShare) which tells the client which media-types are acceptable,
which collections are available etc. APP provides DELETE (which we may
need later maybe), APP defines the status codes, APP is well known and
clients are available for APP.

I know that APP may be a overkill if SDShare mandates that each
SDShare server must also provide the complete APP, but APP is popular,
it's is well known and supported and SDShare could simply define a
subset of APP which MUST be implemented by a SDShare server.
Creation/removal of snapshots could also be handled by APP.

[...]
> Well, SDshare push does use POST, but we post complete feeds for
> the reasons outlined in earlier discussion.

Maybe I missed something, but I cannot find a discussion if a POST of
a collection of fragments is necessary vs. POST of a single fragment.

Why do you think that POSTing a collection of fragments in a single
request is useful?

>> Uploading a collection of fragments would result into multiple POST
>> requests. Using multiple POST requests would also provide a better
>> error handling etc.

> It would also mean a much greater number of requests, etc.

That's true, but I wonder if that's problem?

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
<http://mappa.semagia.com/> Mappa - Python Topic Maps engine