Make CloudRef and CloudArray more consistent w.r.t. IDs

[dsyme]

In the Elastacloud preview edition of MBrace clusters on Azure, the APIs for CloudRef and CloudArray feel a little inconsistent w.r.t. persistence

1. We have CloudRef.Parse(persistentId) but no corresponding CloudArray.Parse(persistentId)
2. In both cases, I feel Parse might be better named Existing.
3. In this formulation the way to get the persistent ID using (cr :> ICloudStorageEntity).Id is not discoverable enough. I think it would just be better to have ID directly on the CloudRef and CloudArray types directly, since the ID is a very fundamental part of these objects.

Thanks!!!! Don

[dsyme]

(this should really have been in MBrace.Core :) )

[krontogiannis]

(Yeah ^^)

• We are currently changing the CloudArray primitive. All of the facelifting takes place in the cloudvector branch. That includes changes in functionality and the API (oh and also the name) and will be part of the next nuget release for MBrace.Streams. CloudVector at the moment, is just an in-memory collection of other store primitives, so I'm not sure a Parse method is fitting. Of course the user could just create a CloudRef<CloudVector<_>> and persist the CloudVector in storage, or we could provide a .Persist method.
• Yeah Existing or OfPath seems better to me.
• I agree, Id should be also a property on those types.

[eiriktsarpalis]

The reason for choosing the name .Parse is that it can be used on any file in the blob storage with a user-provided deserializer.

The upcasting issue in the cloud ref has been fixed in b7aecff35b745a562a7e32e408ca34b45b8171e2.

[dsyme]

OK, great.

A few follow up items to discuss

• The Path/Id terminology seems like it may potentially still be a little inconsistent between different abstractions, but I can see why you've chosen the terminology you have (path for CloudFile/CloudRef and id for CloudAtom).

• What about CloudChannel? It has an identity, but in the current Elastacloud preview it's not so easily available either for creators or users of CloudChannel. You can create like this but I don't know how to get the ID back from an existing cloud channel.

  let channelContainerName = cluster.StoreClient.ChannelProvider.CreateUniqueContainerName()

  let send,recv = cluster.StoreClient.ChannelProvider.CreateChannel(channelContainerName) |> Async.RunSynchronously

• From my limited experience so far, I somehow expect CloudVector (was called CloudArray) to also have a strong ID. I don't really think of it as an in-memory collection of other storage primitives. But that's just based on my initial experience with using them.
• In the current Elastcloud preview, CloudVector (currently called CloudArray) has an indexer which must run synchronously (?). The idea of having an indexer on CloudVector/Array seems wrong unless it has a Cloud<T> return type? Has this been fixed?

Thanks don

[eiriktsarpalis]

@dsyme as to your questions:

• The missing identity properties in CloudChannel have been addressed in the latest MBrace.Core.
• CloudVector is indeed an in-memory collection of CloudSequence's. CloudSequence in turn is a collection of values that have been serialised to a single file in storage. So to answer your question, CloudVector could have a single id, but it wouldn't uniquely identify that particular collection of collections.
• CloudVector no longer carries an indexer. It uses a ToEnumerable : unit -> Cloud<seq<'T>> method. In general the store API has been changed and uses Cloud<_> everywhere.

[dsyme]

Fantastic! Great to know the API is progressing in these directions.

I'll close this out now :)

Best don