Hi DataMappers -- I'd like to develop a (public) DM binding for Read It Later<http://readitlaterlist.com/>, a bookmarking service with a simple REST API (documented here<http://readitlaterlist.com/api/docs/>). This would be a bit like dm-isbndb-adapter<https://github.com/senny/dm-isbndb-adapter>in that it would bundle some resource definitions (in the form of mixins) together with the adapter.
The code for dm-rest-adapter <https://github.com/datamapper/dm-rest-adapter>and dm-isbndb-adapter <http://github.com/senny/dm-isbndb-adapter/> has been helpful, but I could use pointers on a couple of additional specifics. Mentions of other projects that implement similar features, or pointers to source code, past discussions, or documentation would all be appreciated. I've read through pretty much everything at datamapper.org and the last year of the mailing list, but I'm not seeing much information on these topics. Specific questions: 1) Writes should be batched into REST calls that modify multiple records at a time. The natural mapping seems to be transactions. I was thinking I'd keep a buffer of pending updates and flush them out when a transaction closed: Resources <-> DM -> Cache of Pending writes -> Server Is this approach reasonable, and are there examples of other adapters that implement DM transactions in a non-database context? I looked over the dm-transactions <https://github.com/datamapper/dm-transactions> source code, but the mechanics of how DM transactions work are still not really clear to me. 2) There are only two entities in the Read It Later universe: users and bookmarks. However, to access or modify bookmarks, you must pass user credentials to the server with every REST call. I'd like to design the API so that a client can manipulate multiple users' bookmarks; therefore, I don't think I want to associate user credentials with the adapter itself. It looks like the CUD methods in the CRUD part of the adapter have access to resource objects, so I guess I can just call bookmark.user from the adapter in those contexts. But what about reads? They can't be done outside the context of a specific user, so something like user.bookmarks.all(:read => false) is meaningful, but Bookmark.all(:read => false) is not. Would it work to simply include the username and password as part of the User resource's primary key, and to validate queries to ensure that these fields are present as join criteria? (In other words, if you tried that second call, the adapter would see that it didn't have enough information for a query and would just raise an exception.) Thanks for the help! Garth -- You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
