Maciej,
Can you provide me a description of how can I write a bug report ?
Regards,
Vitaly
From: orion-dev-bounces@xxxxxxxxxxx [mailto:orion-dev-bounces@xxxxxxxxxxx]
On Behalf Of Maciej contractor Bendkowski
Sent: Donnerstag, 8. August 2013 15:54
To: Orion developer discussions
Subject: Re: [orion-dev] One more question about Server API / File API
Vitaly,
If you spot any differences as the one you've mentioned, probably the best way is to open a bug under the documentation component.
There you can describe the mismatch you've found and CC the author of the documentation. If you get assurances on what's actually wrong
(documentation and/or API) from the documentation author, you will get the chance to contribute some changes.
Best regards,
Maciej Bendkowski
From: "Kozyura, Vitaly" <v.kozyura@xxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>,
Date: 2013-08-08 15:44
Subject: Re: [orion-dev] One more question about Server API / File API
Sent by: orion-dev-bounces@xxxxxxxxxxx
Maciej,
> If you spot any documentation/real-life differences, please contribute changes to our documentation :)
For example, in the File API documentation I read the following:
“Note that changing the contents of a non-existing file is not permitted. Files are created via POST operations rather than a PUT.”
Otherwise in the Orion instance a file can be created using PUT.
Should I contribute to the documentation ? ;)
What is the truth in this case ?
Regards,
Vitaly
From: orion-dev-bounces@xxxxxxxxxxx [mailto:orion-dev-bounces@xxxxxxxxxxx]
On Behalf Of Maciej contractor Bendkowski
Sent: Donnerstag, 8. August 2013 15:19
To: Orion developer discussions
Subject: Re: [orion-dev] One more question about Server API / File API
Vitaly,
>From what I gather, the last time I had to use the File API I couldn't rely on the documentation in 100%. The documentation isn't always updated after each change, so there might be differences.. I remember there were additional fields in the responses which,
unfortunately, were not mentioned in the documentation. The best way (or actually the quickest) is to browse through a file system on a live instance using Firebug and look on the actual responses. If there are some inconsistencies in the responses - it ought
to be reported and fixed. If you spot any documentation/real-life differences, please contribute changes to our documentation :)
Best regards,
Maciej Bendkowski
From: "Kozyura, Vitaly" <v.kozyura@xxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>,
Date: 2013-08-08 14:38
Subject: Re: [orion-dev] One more question about Server API / File API
Sent by: orion-dev-bounces@xxxxxxxxxxx
Hi Maciej,
Thank you for the quick answer.
My understanding is:
Important parameters are duplicated in the header for caching reason.
They still remain in the body for completeness reason.
Is it ok ?
If yes, is there any description of which parameters (and in which requests) are important enough to be duplicated ?
For example, here (http://wiki.eclipse.org/Orion/Server_API/File_API#Creating_a_directory)
there is no duplication for both ETag and Location.
Regards,
Vitaly
From: orion-dev-bounces@xxxxxxxxxxx [mailto:orion-dev-bounces@xxxxxxxxxxx]
On Behalf Of Maciej contractor Bendkowski
Sent: Donnerstag, 8. August 2013 12:27
To: Orion developer discussions
Subject: Re: [orion-dev] One more question about Server API / File API
Hi Vitaly,
The ETag is basically meant to be used in HTTP cache, so it's quite natural why it's used in HTTP headers along with the location.
In order to better understand why the Location and ETag headers are duplicated in the JSON response, please consider the following scenario.
You are implementing a custom file system plugin for Orion, e. g. google drive. If you take a look at the File API, you'll see why the Location property
is crucial there. You could use it for whatever reason to access the whole file system and perform some operations. Not only on the file which is actually
created, updated or whatever. A more intuitive example is a file system where there's actually no update operation, but only create. How to implement
an update operation over such a file system? You could manually check the file versions, and if it's new, delete the old version using it's location property and save the
new one.
Why duplicate the ETag? Again, imagine a file system where all operations take a lot of time to finish. Why not implement your own cache?
In order to accomplish that without the ETag you'd probably create your own md5 sum or whatever and manually check the versions.
That could be done, but it's error prone and actually slow. So, in this situation the ETag is quite usefull.
I hope that answers your question.
Best regards,
Maciej Bendkowski
From: "Kozyura, Vitaly" <v.kozyura@xxxxxxx>
To: "orion-dev@xxxxxxxxxxx" <orion-dev@xxxxxxxxxxx>,
Date: 2013-08-08 11:33
Subject: [orion-dev] One more question about Server API / File API
Sent by: orion-dev-bounces@xxxxxxxxxxx
Hi all,
I have one more question about Orion File API.
Below is the example response from the wiki page (http://wiki.eclipse.org/Orion/Server_API/File_API#Copying_a_file_or_directory).
Example Response
HTTP/1.1 201 Created
Location: http://example.com/file/MyProj/destination.txt
ETag: "35fd43td3"
Content-Type: application/json
{
"Name" : "destination.txt",
"Location" : "http://example.com/file/MyProj/destination.txt",
"ETag" : "35fd43td3",
"LocalTimeStamp" : "01234345009837",
"Directory" : "true"
"Attributes" : {
"ReadOnly" : "false",
"Executable" : "true"
}
}
The ETag and the Location are duplicated in the header and in the body.
Is there some reason behind ?
Thanks in advance,
Vitaly
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
