This page contains features and other 'wish list' items I've collected while working with Microsoft's SDS. You might notice that most of the requests I list here relate to 'application protocol' level items - HTTP. That's because I am currently most interested in these issues and I have not found too many others covering the same space. I know there are lots of important database-related features that SDS can include, too. I leave the work of documenting those feature requests to others.
The SDS team maintains an active forum for anyone who wishes to join. They also have an SDS Team blog. You'll find lots of the items on this page covered in these other sources. However, I had a hard time keeping track of progress on several of these items. So I started this page to try to keep a easy-to-find linkable list of items related to SDS.
Of course, this list is in no way official or comprehensive. It's not meant to be a 'sink' for SDS feature requests. If you like some of the stuff here - cool. If you think some of it is just lame, I accept that. If you think I've missed some important items, you're not be alone. I encourage you to publish your own feature lists for SDS to consider. Feel free to post your comments on my SDS Feedback page.
Currently SDS a single user account that has full access to all operations (Create, Read, Update, Delete) for all SDS objects
(Authorities[no delete], Containers, Entities). SDS should also provide support for multiple user accounts with
granular access to the same SDS objects. In keeping with SDS's support for REST-like interaction, it is proposed
that access security for SDS be based on permissions (and not roles) and that the permissions
be mapped directly to HTTP methods: POST(Create), GET(Read),
PUT(Update), and DELETE(Delete).
Further, it is proposed that these permissions be applied directly to the URIs that are used to request
SDS objects. For example http://data.database.windows.net [POST, GET] is
a security rule that allows only Read and Create rights for, in this case Authorities. This pattern
can be expanded by using a templating notation (i.e. regular expressions). For example, the following
rule defines read-only access for the selected authority/container:
http://my-authority.data.database.windows.net/my-container/(.*) [GET].
Finally, these security access rules (URI+HTTP-Method-list) can be associated with one or
more user accounts to complete the access control features of SDS. Also, it is possible to associate
one or more security access rules with a role|group and then associate one or more user accounts with
that group. In this way, SDS can implement support for 'role-based' security.
NOTE It is not recommended that access security be based on values that do not appear in the URI (i.e. cookies, custom headers, etc.) since this can break intermediaries (caching, security proxies, etc.) and could result in the exact same URI returning different data to the user-agent based on the contents of these 'hidden' values. For the same reasons, it is not recommended that access security be based on the contents of Entity objects (i.e. Kind) since this is data 'hidden' in the body of the response and not available via the URI itself.
Currently SDS supports the Basic form of HTTP Authentication. In addition, SDS should offer user-agents the option of using the Digest form. Both forms are essential for supporting automated user-agent interaction with the SDS data servers and the Digest authentication algorithm is more secure than the Basic algorithm.
Currently SDS returns a maximum of 500 entities per query regardless of the number of entities that match the query criteria.
Going forward it is important to provide support for paging control. Ideally this should be done as message metadata, not as
part of the query itself. One possible exception would be to use the Take(n) query function currently supported
by SDS as part of the paging control metadata. A good example of a pattern already 'vetted' by the community is the
Feed Paging and Archiving standard developed for the
Atom MIME-type.
Since SDS seems committed to supporting Atom at some point in the future, using the above-mentioned RFC standard seems a good target.
For MIME-types other than Atom, it is suggested that a set of custom HTTP Headers be employed to cover the same values.
Suggested names are: x-paging-first, x-paging-previous, x-paging-next, x-paging-last. In line with
RFC5005 (see above), the values should be links, not scalar values. This allows the greatest flexibility for future changes to the
way paging is used and/or computed (i.e. x-paging-next: http://example.com/container/entity-25)
Another possible solution would be to consider the
HTTP Header Linking
draft from Mark Nottingham (i.e. link:<http://example.com/container/>; rel="first").
While this draft is currently dormant, it has potential for wider acceptance over adopting custom HTTP headers.
application/x-ssds+xml) to identify EntitySet and Entity documents.
It would be better if this custom MIME-type was
properly
registered with the
IANA.
This would make it easier for others to find and build in support for the custom MIME-type.
/container/entity-id) should not
change depending on the MIME-type (i.e. /atom/container/entity-id is not allowed). Text-based
media types that are desirable include
Atom,
JSON,
HTML, and
CSV.
Additional types that would improve the user-agent experience include
PDF and
SVG.
2008-12-03
The SDS team confirmed that, as of the Public CTP release (2008-11), SDS supports the HEAD method for
all requests for 'single' objects (i.e. /v1/[container]) but not requests for 'lists' of objects
(i.e. /v1/[container]?=). I'm still holding out for HEAD support for lists, too.
Using the HEAD method will allow user-agents to check for the existence of a resource (Entity) before making the actual request. This call can also be used to cut down on traffic and bandwidth since making a HEAD call w/ the server-supplied ETag will allow the user-agent to determine if a new copy of the Entity exists on the server. This can improve scalability and runtime performance. Supporting this feature can reduce charges to the SDS account-holder.
2008-12-05 I confirmed that the entity body is not returned by SDS on POST or PUT. This request should not have been included in the list. The only remaining item is the need to return the Location header (see above).
Instead of returning the resulting Entity from a POST or PUT, return the appropriate HTTP Status Code with a Location HTTP Header that points to the resulting Entity. For POST, return 201 (Created). For PUT, return 204 (No Content). This is especially helpful when handling large binary objects as it cuts down on possibly needless traffic and bandwidth. Supporting this feature can reduce charges to the SDS account-holder.