Question about GrainIDs

[jasonholloway]

Hi,

I've been working through the codebase a bit, and I've come to a bit of a wall regarding GrainReferences and GrainIDs - what's the functional difference between them? I really want to understand them like so:

• GrainID - a reference to a concrete grain implementation in some silo or other, encoding the exact type of that implementation, so that it can be recreated if missing
• GrainReference - a GrainID wrapped, a proxy of the targeted grain with exact type information for one of its implemented interfaces.

But the nice conception doesn't hold up: though some bits of the code really suggest the above, other parts complicate it. For example:

• each concrete Grain stores one GrainReference in particular (albeit reconstructed from the activating GrainID), which it uses to identify itself to its storage provider.
• GrainIDs themselves seem to encode interface info, as part of their contained typecode
• GrainIDs are internal only, despite there being a need, in writing storage providers, for a per-concrete-grain identifier.

In short, they're used indistinctly(?), and I'm confused.

The context of this is that I'm trying to make a mock storage provider, and need to match up passed references to grains - hence trying to understand what exactly a GrainReference is, and why it seems to be intermingled with interface information.

[sergeybykov]

GrainId is just an identity of a grain. GrainReference is a base class for generated interface-specific proxies (grain references). It encapsulates the behavior of sending messages to grains while GrainId is just data. That's roughly the distinction.

[jasonholloway]

Is GrainId interface-specific?

[sergeybykov]

It is not. GrainId is an identity of a grain, and a grain class can implement multiple grain interfaces.

[jasonholloway]

What had confused me was that in GrainId creation, the interface type gets passed downstream after the implementation type has been determined - turns out that this is just used in the case of generic types, so that the generic args can be gathered from the interface and used to decorate the base typecode as a secondary operation.

So - that's one of the three mysteries solved.

[jasonholloway]

But, do you mind me asking - is there a reason for IStorageProvider to be passed GrainReference in storing grain state? Seems like GrainID would be the best candidate here.

I take it the main reason GrainID is internal is that the client is encouraged only to deal in virtual references - but in writing a custom IStorageProvider the concern is always going to be persisting concrete types.

[gabikliot]

That goes back to #1123.