# Re: VRML & URIs: Caching, Identifying, and Classifying Objects

Robert DiFalco (difalco@primenet.com)
Sat, 27 May 1995 01:22:56 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Larry Masinter: "Use of Domain Name System for Dynamic References in an Online Library"
- Previous message: Mark Waks: "VRML & URIs: Caching, Identifying, and Classifying Objects"
- Maybe in reply to: Mark Waks: "VRML & URIs: Caching, Identifying, and Classifying Objects"

    Date: Sat, 27 May 1995 01:22:56 -0700

    Message-Id: <199505270822.BAA26062@mailhost.primenet.com>

    To: justin@dsd.camb.inmet.com (Mark Waks), www-vrml@wired.com, uri@bunyip.com

    From: difalco@primenet.com (Robert DiFalco)

    Subject: Re: VRML & URIs: Caching, Identifying, and Classifying Objects

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.

- Next message: Larry Masinter: "Use of Domain Name System for Dynamic References in an Online Library"
- Previous message: Mark Waks: "VRML & URIs: Caching, Identifying, and Classifying Objects"
- Maybe in reply to: Mark Waks: "VRML & URIs: Caching, Identifying, and Classifying Objects"