From: "Ronald E. Daniel" <email@example.com> Message-Id: <9506231252.ZM5744@idaknow.acl.lanl.gov> Date: Fri, 23 Jun 1995 12:52:16 -0600 To: firstname.lastname@example.org Subject: FWD: SGML URC spec comments (3/4) This is Brian's reply to my reply. --- Forwarded mail from Brian Behlendorf <email@example.com> Date: Fri, 23 Jun 1995 01:39:51 -0700 (PDT) From: Brian Behlendorf <firstname.lastname@example.org> Subject: Re: Agent-mediated access (was Re: Criticism of Kidcode...) To: "Ron Daniel Jr." <email@example.com> On Wed, 21 Jun 1995, Ron Daniel Jr. wrote: > Thanks for the quick turnaround on your comments. May I have your permission > to forward your message to the URI list? Um, sure, if it doesn't expose my ignorance too much :) > > Well, in the object-oriented model, "POST" is not just a way to send more > > information up the pipe in the request. "POST" is defined to be an action > > which modifies a resource or creates a new resource; thus, the request and > > the response is never cached automatically. Meanwhile, "GET" is defined to > > be idempotent - it doesn't change anything, and thus it can be cached and is > > considered "safer". Now, you and I know that there are scripts out there > > that violate this - I've built several myself. However, the > > object-oriented model is something we should try and keep sacrosanct, in > > specification at least. > > Yeah, GET would be the clean choice, I just recall having argument length > problems with it. I haven't tested any of the new servers for such problems. > Do you know what the limits are for Apache? There's a new version being tested that does away almost completely with static memory allocation, meaning it could be as long as needed, I think... but there's still limits in caches and proxy servers that need to be considered. Ugh. > Hmmm. I don't see URCs as analogous to SOAs, at least as far as I know about > SOAs. An SOA implies authoritative information. I don't regard URCs as > authoritative. Which is more authoritative - the publisher's URC for a > resource, the Library of Congress' (which will be prepared to a higher > standard), or any of the other URCs that can exist for a resource. This is > related to a later question of yours about non-publisher supplied metadata. This is true, however I need a way to tell if a URC I find is a recent copy, is still "fresh", yes? I guess that's not much different than asking a proxy asking a server if a given HTML document is fresh (by sending an if-modified-since request).... > This issue keeps coming up, so I am not doing a good job explaining that > anyone who wants to can establish a URC for a resource. It is just a question > of how to find it. Aaah, okay. Now the SOAP solution becomes clear. > The publisher's URC is the "default" URC for a resource > since under most URN models, the publisher's name is used in the resolution > process. However, I could have a browser that talks to a particular > URC resolver by default, such as the one at the schools firewall that > snarfs the PTA's URCs nightly. I could use a URL to connect to OCLC's > URC server, give it a URN, and get their URC for the resource. Okay, that all makes sense. > If the VRML folks define a naming scheme, and basic URCs for common > objects, VRML developers could use those names, provide URLs for their > own objects, and away you go. It's the naming scheme that I'm unclear on, but I need to read more URN stuff I suppose. For the time being we'll be setting up an object hierarchy under http://www.vrml.org/objects/ or some such, with the hope that this resource will be replicated to large servers elsewhere. i'm supposing from a quick glance that a generic teapot might be something like: <URN:vrml:www.vrml.org:teaport> ? > Have you seen the PRDM work out of Stanford? Take a look at <URL:http:// > www-diglib.stanford.edu/rmr/TR/TR.html> if not. This is the sort of > annotation system that I have in mind. I've had a lot of conversations with Christian Mogensen about stuff like this. I definitely think this is the right direction. In fact, I hope they're writing a Java front end to handle the extra GUI for these functionalities. While at HotWired I tried to wrestle with this for HW's conferencing system, and even came up with a cool design using a LINK HTTP method, but obviously the inability to change or influence client extensions to support this made it imposible for that situation. However, with Java... > > Compelling applications! That's all you need, history tells us :) > > True, quite true. I'll do my bit to get this into web sites we build, as long as the clients are built by someone! Brian --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- firstname.lastname@example.org email@example.com http://www.[hyperreal,organic].com/ ---End of forwarded mail from Brian Behlendorf <firstname.lastname@example.org> -- Ron Daniel Jr. email: email@example.com Advanced Computing Lab voice: (505) 665-0597 MS B-287 TA-3 Bldg. 2011 fax: (505) 665-4939 Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, 87545 tautology: "Conformity is very popular"