[glue-wg] Capacity representation

[Burke, S (Stephen)]

Paul Millar [mailto:paul.millar at desy.de] said:
> I think this illustrates our different points of view.  If I 
> may summarise 
> your position (please correct me if I'm wrong), you see 
> object classes as 
> necessarily being something concrete---something you can (in 
> principle) hold 
> in your hand (e.g. a cup), or that you could separate and 
> similarly hold in 
> your hand.  From your point-of-view, a smile cannot be held 
> in a hand, so necessarily cannot be an object.

Well, not quite - the question for me is whether you could have a
specific instance of the thing which is detached from the parent. Things
you can hold in your hand will obviously fall into that category, but
more abstract things might as well - indeed a VO is something like that,
the atlas VO is a rather abstract idea but still has a definite
existence independent of its members and is definitely not the same VO
as cms. Maybe there are contexts in which a smile could be separately
identifiable, e.g. clowns "register" their facial design, or there might
be a specific "style" which would allow you to say that two people have
the same smile (identical rather than equal).

> If so, I see I have a different point-of-view.  For me, an 
> object class is any 
> well-defined logical concept defined only by its 
> relationships with other 
> object classes and the attributes it may have (there are 
> probably some stronger statements one can make).

But what about *instances* of the class? Some classes can have definite,
identifiable instances and some can't. (You can also get into
metaphysics here, e.g. are all instances of the integer "3" identical?
:) I did a course on python last week and the way in which it treats
things as identical or not was the bit I found hardest to grasp, e.g.:

>>> a=[[0]*4]*4
>>> a[0][0]=1
>>> a
[[1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0]]

So four out of the 16 elements are identical ...

> http://images.google.co.uk/images?um=1&hl=en&q=smile&btnG=Sear
> ch+Images

So which of those share the same *instance* of a smile? Compare with,
say, photographs of cars, where it would make sense to say that all cars
of a specific model share a single "model" instance, even though that's
also an abstract concept.

> OK, counter example.  When you buy the mug at the shop, they 
> give you a till receipt (typically).

Yes, and that would be a different context. In fact I was going to give
the alternative example of rental, where you have a rental contract that
defines the relationship, so it does make sense to ask which things
belong to which contract. For ownership the contract normally only
applies at the point of purchase, so in most contexts it isn't relevant
to ask whether things were purchased together or from the same supplier
- but if that's the context you're working in then indeed the
relationship may become concrete and you could talk about a specific
instance of it (these three books belong to me by virtue of this
specific invoice from amazon).

> Your ownership is transferable (you give the receipt and mug 
> to someone else whilst in the shop, they walk out with the mug)

Possibly diverging too far from the subject, but I don't agree - the
shop sold it to you regardless of the fact that you give the mug and
receipt to someone else, so the ownership *instance* doesn't transfer
even though the ownership does (it now derives from an implicit contract
with you). Conversely, if someone steals the mug and receipt that
doesn't give them legal ownership.

> and sharable 
> (a group of 
> people all club together to pay for the mug, they sign a 
> document saying they 
> have part-share of the ownership, the two documents are 
> stabled together).

Then you create a new object (the club) which uniquely owns the mug and
which has the people as members.

> > if I own two mugs and give one away it doesn't affect the 
> > other one
> 
> True, no one suggests that it is should affect the other.

As I say, if you consider object instances (which we obviously will when
we implement it) it's a vital distinction - if two objects share the
same instance of another object then one *will* affect the other (see
the python example above). If I rent both mugs under the same contract
and the contract gets terminated then I do lose both together.

> (I fear you're grasping at straws here ;-)  Network 
> infrastructure (networks, 
> routers, firewalls, etc...) connects everything together, 
> this isn't special 
> about CEs and SEs that they require network connectivity.

What's special is that the network path allows e.g. dcap to work (no
firewall blocks) and has sufficient bandwidth to support it. That's a
well-defined feature of the path, it applies to any connection between
the two domains and a single change (e.g. a firewall block in the
middle) would block all of them. Hence it does make sense to say that
there is a single instance of the dcap "binding" over that path,
independently of what happens to be at either end.

> OK, I accept the analogy: comparing an AccessProtocol to a 
> handle of a mug 
> (more or less) works, although there's a few questions about 
> the similarity 
> of snapping off the handle vs. "detaching" an AccessProtocol.

Not so much, you could turn off the SRM but leave the gridftp server
running (and obviously vice versa).

> But, this then leads to the question: what is it about the 
> handle of a mug 
> that means you're happy describing it with an object?

Intrinsically it's probably that I could give a name (UniqueID) to that
specific instance - for the capacity I can't, it has no identity of its
own.

Stephen