fsprojects / FSharp.Azure.Storage

F# API for using Microsoft Azure Table Storage service
MIT License
75 stars 16 forks source link

Move to fsprojects? #5

Closed dsyme closed 9 years ago

dsyme commented 9 years ago

Hi Daniel

Would you consider moving this to http://github.com/fsprojects/? That an be a good way to get more eyes on the project (and contributors too). Either way I'm interested in the project and am looking forward to taking a closer look at it.

Cheers! don

daniel-chambers commented 9 years ago

It's probably not a bad idea. I had a quick search but I couldn't find any onboarding documentation for fsprojects. Do you know of anything I can look at?

dsyme commented 9 years ago

You just transfer ownership to https://github.com/fsprojects-transfer/ using GitHub's "transfer project" feature. We then complete the transfer to https://github.com/fsprojects. You remain admin on the project.

Beyond that, there's nothing except that

dsyme commented 9 years ago

I added a version of this info here: https://github.com/fsprojects/FsProjectsAdmin/blob/master/README.md

daniel-chambers commented 9 years ago

Thanks Don. The transfer is in progress.

dsyme commented 9 years ago

Move completed! https://github.com/fsprojects/FSharp.Azure

(As an aside "FSharp.Azure" is a very broad name and it will make sense to clarify it, I need to look closely at what it's doing though)

daniel-chambers commented 9 years ago

Cheers.

FSharp.AzureStorage is probably a more focused name, because the library deals with Storage. At the moment it's just table storage, but I do want to expand the capabilities to blobs and queues eventually.

dsyme commented 9 years ago

Following the guidelines I think it would be FSharp.Azure.Storage (to align with the use of FSharp.Azure in the FSharp.Azure.StorageTypeProvider name - t he guidelines ask for consistent two-word namespaces FSharp.Control, FSharp.Data etc.).

Do you think FSharp.Azure.StorageTypeProvider and FSharp.Azure.Storage (this project) overlap or are sufficiently orthogonal? Would this naming be good or bad?

CC @isaacabraham

Thanks! don

daniel-chambers commented 9 years ago

The names certainly overlap, but I think the two projects come at storage from two different perspectives. FSharp.Azure assumes your tables are empty and that your code defines the types they contain so that your code can insert and query the data. FSharp.Azure.StorageTypeProvider assumes your tables contain data and generates types to match. I see the former being more about writing and reading data, and the latter being more about reading existing data super easily.

Thoughts?

dsyme commented 9 years ago

I see. I think I'm ok with the overlap for now.

I guess ultimately we may try to converge the two to one project that allows smooth transfer between either approach. (e.g. so FSharp.Azure.StorageTypeProvider can provide tables fitted to FSharp.Azure-style types).

isaacabraham commented 9 years ago

Hi! Actually you can insert data with the TP into completely empty tables - the TP will just use reflection to pull out any properties it can and generate an insert statement. The only restriction is that the table itself must exist (and since 1.2 that was somewhat alleviated as you can fall back to the native SDK directly within the TP).

There's actually quite a lot of overlap in terms of enhancements over the stock SDK e.g. I think both offer improvements to batch inserts; and whereas early versions of the TP were indeed geared towards read access it now has a decent story for write access.

The biggest difference I think about Azure.Storage and the TP is that the former offers a much more idiomatic FP way to interact with tables - the TP is a bit of a halfway house in this regard (although to be fair that's often the case with TPs).

It would be great if we could compose the two somehow but I've always struggled with referencing dependencies from type providers and distributing via NuGet - the way the native sdk is bundled with the TP is a total hack.

I agree that an objective review of both would be useful to isolate differences and features that could be shared somehow.