EVE Technology Lab

If you don't care about checking the header or checksum on PHP you can use method given in http://us3.php.net/manual/en/function.gzdecode.php#106397 instead of the more complex function Desmont McCallock linked. The other function seems to be more for dealing with a group of compressed files or a more complex header then you seem to get from gzencode() or would expect to see in HTTP.

Unless there is any technical reason not to do so, I'm going to yank that GET upload part from the spec. It's absolutely useless, and doesn't even make sense as far as HTTP is concerned. Due to the length limits discussed earlier, this becomes a non-starter for the vast majority of servers (unless you're a bonehead and up your limits, opening yourself up to some pretty silly GET requests).

I know who did it but I'm not a snitch. For the record it wasn't me (although I added the notice).

Can we get rid of the PUT method, too? I don't see any reason to put additional burden on service developers to support this if there's no reason. As discussed earlier, it's not technically correct to use PUT unless you know the exact URI of the item you're PUTting.

Can we now update the wiki and change the spec version from '0.1alpha' to '0.1'?

Just chiming in.
I've seen in a parallel topic, that there's a concern about the data acceptance. (I.e., we can upload the data, but can we know, if our data could be accepted, before we start sending a payload?)
So, for a suggestion: How about a simple discovery sequence?
Something as simple, as

{
  "resultType" : "discovery",
  "version" : "0.1",
  "generator" : { "name" : "Yapeal", "version" : "11.335.1737" },
  "currentTime" : "2011-10-22T15:46:00+00:00"
}

with the answer (if the outlet is really accepting EMUU format) like

{
  "resultType" : "status",
  "version" : "0.1",
  "status" : "unavailable",
  "message" : "Human-readable explanation of the server status, intended to be displayed to operator.",
  "generator" : { "name" : "Yapeal", "version" : "11.335.1737" },
  "currentTime" : "2011-10-22T15:46:00+00:00",
}

I would recommend to perform a discovery at least once per client session.

I would also advise to use HTTP status codes accompanying the reply, in the range of
Status / HTTP code
available - 100 Continue or 200 OK
unavailable - 503 Service Unavailable or more appropriate code from 4xx range

Also on the note of status codes, I've noticed that specification does not clarify format of server responce to the uploads. And as I've seen in this and other topics, this already leading to some confusion.
I strongly suggest using the same tatus form as above, with status=accepted/HTTP code 202 for succesful uploads, or a proper 4xx/5xx error status for rejected uploads.

@Tonto
Post 1
The 'discovery' proposal will solve also my concerns on determining which server is alive before constructing the message. I now have to include an endpoint in the message without knowing if it's actually online. If the upload fails I have to suspend that endpoint and eventually disable it if uploading to it fails continuously.

As for the reply message, from my POV what to use is quite trivial, but should be documented in the specs and clarified.

Post 2
Probably separate handling scripts.

That's right, but there's a problem.
Format itself isn't a solution to a problem.
The solution is a way to interchange the data in a way that is understood at all ends of the exchange.
You need not only format to describe the data, but a protocol to transfer it as well.
I've already seen something along the lines of "I do "echo 1" to mark a succesful data transfer.
If i'm to develop an uploader myself, what should I do? Should I expect that "1" as the reply to my upload?


First, i'm not going to discuss the transport layer.
My concern was about exact states of a transaction, not the process of it.
I.e., "a client open a connection" does not specify, what connection it is. A UNIX socket, a HTTP server port or a shared memory area? Client open a connection, that is suitable for data transfer. doesn't matter, which connection it is.
Next, client sends a payload. How? Doesn't matter, really. Format matters. The one we described earlier.
Next, server should somehow signal to client, that it accepted the payload. It is a required step in about any stateful communication protocol you could find. If you're operating on raw TCP sockets, it's quite easy, but in most other cases, you'll need server to send something more meaningful. Probably suitable for operator's eyes, too. Especially in case of errors.
I'm up for HTTP codes myself, when it's operated over HTTP, there's plently for most of use-cases, and a room to invent more, if need. But this should be clarified in specification.


The problem was outlined earlier by Desmont, and more thoroughly explained in his post regarding uploader integration in EVEMon.
If we'd take your approach, I could, theoretically, put "http://microsoft.com/" into list of outlets, and spam it with megabytes of market uploads.
While funny as it is, I would take any steps in my reach to prevent this kind of things from happening. It's just not nice to the community.


What I should or not, poses a communication issue along with a possibility of human mistakes.
While i'm against solving social issues with technical solutions, if I can prevent basic mechanical errors at the application design stage, I would do so.

I think HTTP codes are the way to go with denoting whether a response succeeded. Get a HTTP 200, everything is peachy. See some of the 4xx and 5xx codes? You probably have problems, read the body or status text for details.

"All of the discovery requests" would be less than 1% of the total traffic. Even if performed before each upload, which should be strongly discouraged.
Also, you're viewing the situation from your own idealistic POV, assuming that everything should work as intended. Reality says, it doesn't...