Welcome to the group Chad!
I have not been able to spend much time on REST-3D for a while, but I am now in a much better position and will start again spending time moving this project forward.
SigGraph is approaching soon, and I would like to get design discussion going and see if we could gather again this SigGraph in LA. How many people in this group would be interested? We could potentially set up a BOF if not too late
In the mean time, I plan to restart the discussion in the group and the work on the spec, as well as releasing some opensource software.
Regards
-Remi-- RemiFrom: Chad Austin <ch...@imvu.com>Sender: 3d-...@googlegroups.comDate: Thu, 7 Jun 2012 18:03:57 -0700 (PDT)To: <3d-...@googlegroups.com>ReplyTo: 3d-...@googlegroups.comSubject: [3D-REST] IntroductionHi all,I am a technical director at IMVU, responsible for client technology. We have an enormous catalog of user-generated content and are beginning to look into WebGL and exposing that data over a RESTful interface. I'm joining this group to see what others in the WebGL space are doing and how we could potentially mash up our content with third-party content sources.Nice to meet you,Chad
headers: {
'X-My-Custom-Header':'png';
}
GET /texture/A
Interesting topic. I am not yet grasping why http headers would be better.
Using URL to explicitly ask for a specific format still seems easier/shorter, than using http header
CompareGET /texture/a.png
Withheaders: { 'X-My-Custom-Header':'png'
; }
GET /texture/A
If one want texture A in jpg, simply ask for /texture/A.jpg
What headers let you do is to ask for a set of possible formats and you get randomly one of the supported format back. I'm not sure Iike this too much as would like better control to what I get back from the server.
On the other hand we do need a way to discover what formats are available from the server. This could/should be one of the API calls ?
This said, I'd rather have some formats that are specified by the REST-3D specification that a server HAS to provide, this would make this API more usable/reliable. The goal is to make it easier to write client code, and bring the conversion work on the server.
When we will look in details how the client may request specific structure for vertex data for example, we may not be able to create a mime type for all combination we possibly want to offer.
This said, I'd rather have some formats that are specified by the REST-3D specification that a server HAS to provide, this would make this API more usable/reliable. The goal is to make it easier to write client code, and bring the conversion work on the server.
On 06/08/2012 06:37 PM, R?mi Arnaud wrote:This doesn't have to be one or the other, and at least some knowledgeable people suggest it should be both: http://www.w3.org/2001/tag/doc/alternatives-discovery-20061101.html Having URLs for both the generic resource and the specific resources serve different use cases.Interesting topic. I am not yet grasping why http headers would be better.
I think this is the real challenge here -- for various resource types I can think of a number of properties, some even continuous values like quality, that aren't addressed by the current headers. Quality is an obvious one. It's definitely not the right thing to do to try to encode all of that in mime types; any response type with a particular bit stream format should get a mimetype. Something like quality clearly is outside that scope.This said, I'd rather have some formats that are specified by the REST-3D specification that a server HAS to provide, this would make this API more usable/reliable. The goal is to make it easier to write client code, and bring the conversion work on the server.
When we will look in details how the client may request specific structure for vertex data for example, we may not be able to create a mime type for all combination we possibly want to offer.
X-Max-Image-Size: 16
That's important for *responses*, not really for requests.
I agree with Rémi on this one: extensive use of HTTP headers is
cumbersome for clients. It's much easier to have explicit URLs using
query parameters, rather than having to send Accept headers and then
detect what type the server sent back to you.
When I download metadata about an object, the server should give me
information about what formats the mesh and its textures are available
in, along with URLs for fetching them in the desired format. Let the
application make decisions at a higher level instead of having to mess
with HTTP headers.
BTW, I made more investigations, and the caching does not work at all with 'Vary'.Same issue with CORS AFAIK (http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing)
On Sun, Jul 1, 2012 at 2:52 PM, Jeff Terrace <jter...@gmail.com> wrote:That's important for *responses*, not really for requests.
I agree with Rémi on this one: extensive use of HTTP headers is
cumbersome for clients. It's much easier to have explicit URLs using
query parameters, rather than having to send Accept headers and then
detect what type the server sent back to you.I've heard that claimed a couple times on this list. Can you elaborate on the difficulty of setting HTTP headers in requests?Every HTTP client library I've ever used makes it easy to set HTTP headers on a request.However, I do understand the value of being able to direct-link to some content in a particular format, even though we don't need it yet at IMVU.
If you REQUIRE that a URL contains type information, then that type information bleeds into any linking documents, such as the outfit.
On Mon, Jul 2, 2012 at 3:46 AM, Chad Austin <ch...@imvu.com> wrote:
>
> However, I do understand the value of being able to direct-link to some
> content in a particular format, even though we don't need it yet at IMVU.
> Along those lines, we intend to support a content-type query parameter to
> override HTTP content type negotiation, a la
> /some_texture?content-type=image/png.
This is important, IMO. Being able to link directly to a specific
format of an asset is something we should want.
On Mon, Jul 2, 2012 at 12:46 AM, Chad Austin <ch...@imvu.com> wrote:
On Sun, Jul 1, 2012 at 2:52 PM, Jeff Terrace <jter...@gmail.com> wrote:
That's important for *responses*, not really for requests.
I agree with Rémi on this one: extensive use of HTTP headers is
cumbersome for clients. It's much easier to have explicit URLs using
query parameters, rather than having to send Accept headers and then
detect what type the server sent back to you.
I've heard that claimed a couple times on this list. Can you elaborate on the difficulty of setting HTTP headers in requests?
Every HTTP client library I've ever used makes it easy to set HTTP headers on a request.
However, I do understand the value of being able to direct-link to some content in a particular format, even though we don't need it yet at IMVU.
...
If you REQUIRE that a URL contains type information, then that type information bleeds into any linking documents, such as the outfit.
I agree with Chad's points.... because as I said in my last post URI are opaque resources with N representations. It is counter to the URI spec and its design to make a URL point to a specific representation (content media type) of a resource. The Web is not brittle thanks in large part to this distinction. Let's not lose it.
ps: I think it's actually anachronistic that ".png" in the path part of a URL conveys any sense of media type. A URL is not a file system path!
On Wed, Jul 4, 2012 at 3:15 PM, Mark Barnes <ma...@mechnicality.com> wrote:No, Content-Type is used in an HTTP request only for PUT and POST, not GET. See:
> I dont think the HTTP spec supports your assertions although perhaps I
> missed a relevent section ...
>
http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Requests
On Wed, Jul 4, 2012 at 1:08 PM, Jeff Terrace <jter...@gmail.com> wrote:
On Wed, Jul 4, 2012 at 3:15 PM, Mark Barnes <ma...@mechnicality.com> wrote:No, Content-Type is used in an HTTP request only for PUT and POST, not GET. See:
> I dont think the HTTP spec supports your assertions although perhaps I
> missed a relevent section ...
>
http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Requests
hehe lol ... wikipedia is not an authoritative source my friend! I will stand by the HTTP spec until convincing proof is offered to the contrary. :)