Cds versus .NET dataset

I followed Bill Todd's advice in a question I put on Borland newsgroups related to comparison of cds and .NET dataset and finally purchased a copy of ADO .NET book by David Sceppa.
I've been reading for a couple of days now and my first impressions are:

• Even though, ADO .NET is radically different in design compared to DataSnap, there are a lot of common concepts and things that could make a developer using one technology to port to the other.
• Terminology differs (as expected). For example, Cds.MergeChangeLog is similar to Dataset.AcceptChanges and Dataset.Merge has similarities with RefreshRecord. That makes things rather complex for a developer who would like to be able to use both technologies. What I've been thinking is that I (with my components) contribute to this chaos. For example I use the term hierarchical cds to refer to self-referenced datasets that can be used with tree- view like components, whereas in the book I'm reading it is equivalent to nested dataset structures (master-detail-detail...). In addition, may be it should be better to rename IsClientServer property of my components to something similar to AutoIncrementStep and introduce AutoIncrementSeed property as ADO .NET does, so that it becomes easier for a developer (used to develop on ADO .NET) to get accustomed to my components.
  
• I have already posted that I try to mimic some of .Net dataset features building my components. My main problem at this point is to support other kinds of fields beyond TIntegerField. TNumericField descendants would be quite easy, but TStringField type fields require some special considerations, related to how autoincrement behavior should be handled. I'll continue reading this excellent resource and may get some ideas.
• In ADO. NET, when updating changes back to the database and if a primary key value changes (through a back-end database generated value) then this value is propagated back to the "client" and then built-in mechanisms of .NET dataset enforce referential constraints. That reminds me of my first implementation of my components. As implemented at this point, all of this "work" is moved to "server side" and is performed by my provider component. I don't know if this is a better solution, I just followed this (more complicated) approach by intuition, because this way I think have better control of the procedure of applying updates (not proved though). For example, I thought that this way I would be able to handle better situations like updating self-referenced (hierarchical) datasets or handle circular references (at this point I am definitely not satisfied with the way I support these cases)
  

I'll keep on reading this exellent book and may be I'll post a (simplistic) summary of what I think are the most significant things to be considered by a developer, so that moving from Datasnap to ADO .NET (and vice versa) could become easier. I am not aware of any resource that already does that.