not sure what the URI list is or means here

We need to have some form of authentication though, because we do not want to open the SWORD flood gates to every SWORD client out there. That can be done at different levels (IP, HTTP, SWORD native auth if there is such a thing), but we will need *something*

i'm guessing less, maybe 100 MB?
maybe ask the HAL folks if they were planning to have limits (we will need our own limits anyhow, but it will give us a rough idea)

We need to decide where this URLs will be rooted, in the general space of SWH service URLs. I see you use sword.s.o below, but I don't quite like it. SWORD is an implementation detail, what we're implementing is a deposit service. So maybe it should be something under archive.s.o/deposit/, or something such.

Aside from that, a nitpick: IIRC for the archive API we use /1/ to denote a version; using /v1/ here is incoherent with that.

maybe just Software Heritage Archive here?

this does not concern the HAL folks, but we will need to decide how to process these one-off loading jobs. It might be related to the distro loading discussion we're having on swh-devel

we're a software archive, and software is the only thing we accept, why do we need to repeat "software" here? what is this endpoint doing?

Well, my understanding of some part of the spec is not crystal clear.
What I understood about this (after reading other sword implementations) is that for auto-discovery reasons, we should list the possible endpoints to access. This is the list of URI mentioned.

sword specs:

The SWORD server MAY include zero or more sword:service [SWORD003] elements as children of the app:collection element containing references to nested service descriptions

Of course, SWORD003 link is not clear either.

I'm not sold on this though so i need to triple check (for example, i don't see what they mean by nested).
At worst, it's not a blocker since we could drop this altogether (the sword specs use the word MAY).

Ok, we can we start with something basic as we did with the archive before it went public (http access restriction).
If it's ok, as it's not enforced by the source code, this can stay out of the specs, can't it?

i'm guessing less, maybe 100 MB?

ok

maybe ask the HAL folks if they were planning to have limits (we will need our own limits anyhow, but it will give us a rough idea)

Well, they don't have any idea yet. (I already asked them :)

Yes, sword.s.o was something simple to avoid a hole in the spec.
But indeed, trying to match our api documentation is a good point (to explain at one location where the root point is).

archive.s.o/deposit/

This sounds reasonable.

/1/

Yes, fixed.

Yes.

this does not concern the HAL folks,

Indeed, the *spec* is HAL agnostic. HAL was merely mentioned as an example.

but we will need to decide how to process these one-off loading jobs. It might be related to the distro loading discussion we're having on swh-devel

Well, as a first approximation, we could simply send a task to a specific queue and creating specific origin with type hal.
The visit notion, while awkward in naming (or is it?), has what we need for the injection.

But sure, I shall read the discussion again.

we're a software archive, and software is the only thing we accept, why do we need to repeat "software" here?

I'm trying to respect the specification.
But i may be able to simplify this part :)

what is this endpoint doing?

This is the subtitle of the previous chapter. It needs to be completed.
Still, it's supposed to be the collection endpoint to post/create a deposit.

The only collection we have, 'software' being what we act upon.