- From: Robert DiFalco <difalco@primenet.com>
- Date: Sat, 27 May 1995 01:22:56 -0700
- To: justin@dsd.camb.inmet.com (Mark Waks), www-vrml@wired.com, uri@bunyip.com
Justin, > >Someone is inevitably going to say, "Oh, that's a browser issue" or >"Oh, that's orthogonal to our bailiwick." You may even be right. My >point is that, at this point, *we don't know*. We need to decide >whose problem this matter is, so they can work on it. > Funny, I just left a message about this subject. To me, it seems clear that this issue is a software issue and not an object specification one. My opinion is that we (we being Internetwork users) need a component model for our tools. In this model you have client components (such as a browser or authoring tool), server components, a "transport agent" component (to generalize disparate protocols like HTTP, FTP, network or local file systems, etc with a single interface), and a replication component. The replication component would be an optional component; that is, client and server components would work the same whether a replicator component was present or not. If it *were* being used, it would be used by the transport agent. The transport agent keeps a log of object requests and, therefore, can be used in concert with the replicator to do "smart" replication much like a generational object memory scheme. The important issue, however, is the level of object granularity. What is replicated is not just composed objects like Lotus Notes does, but the sub-objects that make up a composed object. This scheme not only speeds access to "most used" common objects but provides an abstraction layer to enable the concept ofr a ubiquitous network or ubiquitous data. That is, a transport agent provides the functionality to (for example) design a desktop that is able to access data objects from anywhere, whether it is on the Internet, a local are network, some other wide area network, local persistant storage or volatile memory. Okay, now this is just a concept or product idea, no one group today is going to create the standards to do accomplish this. BUT... this *is* the direction things are headed and when one is designing additional functionality for the Internet one should always strive for a generalized soloution even when a specific soloution would be easier to implement. This is why I believe that while caching shouldn't be crippled by an object specification, it doesn't belong *in* an object specification. As well, protocols shouldn't require cahcing but, rather, enable it. > >Now, a number of people have objected to this, on the theory that if >we encourage sharing of objects, cyberspace will quickly develop a >deadening sameness -- everyone will use exactly the same objects, and >worlds will all look alike. > I personally don't think that this argument deserves consideration. No one, for example, would design a language without references of some sort. And, it is generally accepted that object memory is a good thing. As for the above argument, If anything, sharing objects will increase the amount of information a person can chew by organically encouraging information authors to use common visual metaphores (like under-construction) in the same way that an operating system becomes more usable when applications are encouraged to use common interfaces. Furthermore, no optimization scheme for object retrieval will spontaneously cause the spirit of individuality to combust. ie: its *hard* to cause people to create things in a similar, not easy. > >and hopefully being able to distribute a CD-ROM of the really common >objects, so they don't have to be loaded at all. > Actually, by using a transport agent and "smart" replicator, client (a browser being a specific example of a client component) shouldn't care at all where it is getting something from. It just needs to fufill its request. It only says "give me this" or "take this away". To the transport agent, ram is quickest, next is the hard disk, then a CDRom and finally a network or modem connection. Data will be retrieved from wherever it is most current and immeadiately available. > Scheme A > > The simplest approach just uses URLs, and doesn't especially require > any changes. Some altruistic sites declare themselves to be standard > object repositories. Even if they were that altruistic and responsible, it wouldn't necessarily give you an performance gain, just space reuse. > Scheme B This is better. > Scheme C Nothing particularly wrong with this but it seems a little specific. What interested me about it, however, is that when there is a phone represented in a world, I could concievably use *my* phone. That is, the phone that I like or designed myself. In fact, I could decide that in every world that contains a phone it displays my phone. Furthermore, disparate worlds could use my desk, my table and my teapot. If we could accomplish this, it would provide the functionality to accomplish what you have proposed. In other words, we would have created a generalized soloution that provides more functionality than merely reusing objects. Say that you have three possibilities for any given sub-object within a VRML object. 1. The common (or default) object 2. The author-specified object 3. The user-specified object This can be further compressed to two possiblities. 1. The common (or default) object 2. The specified object Initially the "specified object" is defined as being the object that the author has created through the use of VRML. Phone = { authors VRML composition of a phone } "Phone" not only provides the lvalue or variable name for the object the author is creating but equally important, provides the generalized name or identifier for the common object. In other words, the above single construct provides the information to load the common\default object (Phone.wrl in this case), the authors idea of a phone (the rvalue next to "Phone") and finally the users preferred representation of a phone (stored by the browser in something like a hashed dictionary with key pairs { "Phone", MyPhone.wrl or MyPhone node } ). I kinda like the idea, but, unfortunately, it is object format specific. That is, it will only work with VRML and I'd like to see it work with everything. For example, I might want to have all documents use my "under construction" graphic or my "bullet point" graphic much in the same way that a browser lets me use my font or as another example how Windows allows me to specify my icon to represent a file on the desktop. I guess, in any event, a more general soloution for named objects in VRML would be benifitial. Robert I'm being really verbose lately, so please forgive me all the extra bull-shit in these messages. I'm sure I could have said all of this more tersely.
Received on Saturday, 27 May 1995 04:23:28 UTC