make use of entity metadata

Anything new about that? Let's avoid duplicating all that code for implementing entity CRUD & access if possible.

Personally, I do think the d6 <-> d7 transition is a good opportunity to break APIs, as module authors have to adapt their code anyway. Having to different services APIs (7.3 + 7.4) might pose transition troubles when multiple modules rely on different versions.

Anyway, I'll try to convince you. First off, please read my blog post, which introduces entity metadata in general.

As I've written there I think Services would be a natural fit to use entity metadata. I think it could benefit much from it, here some advantages coming to my mind:

• Benefit from existing module integration. Entity metadata can already do full CRUD for all core entities + it determines access for that. Modules introducing new entities are likely to integrate with entity metadata fast, as it's need to make use of it with Rules.
  But apart from this entity level integration, there is property level integration. It incorporates property level view + edit access restrictions. For fields, field access is incorporated, but there is also access info for regular properties. E.g., changing the node published status is up to users with 'administer nodes' permission. Shouldn't Services with regular session auth respect that too?
• Having metadata available for services surely pays off. E.g. you could use it to automatically generate Service API documentation. Servers could use it too, e.g. the SOAP server could generate proper WSDL.
• Exposed data structures would be more simple and correspond to the metadata. E.g. a simple text field value won't sit in $node->field_name[$langcode][0]['value'], instead $data['field_name'] does it. Oh and it would also take over text processing, if activated. Thus the real internal data structure gets hidden and is streamlined to make more sense. Also that way a module changing its internals, need not be reflected in a Service change!

To actually do the integration, I see two ways to go. 1., depend on Entity Metadata. 2., don't depend on it and ship services integration with Entity Metadata, but don't provide another one. That way modules could choose whether they need core-resources or not. Probably most modules would need it anyway, so probably 1) is better.

Disadvantages:

• A new dependency, the Entity API. However, lots of sites will have it anyways as Rules + modules relying on it (ubercart, drupal commerce,..) will need it anyway, as well others that already make use of it (media, profile2, searchapi, ..). Also we have the plugin manager in core - installing a module shouldn't be so much work any more ;)
• As described in the third point above, the exposed data structure would change. However when migrating from D6 to D7 it would change anyway.

Unrelated to that, when introducing the dependency you could also make use of the entity crud API to simply turn the services endpoints in exportable entities + make them fieldable. I do it that way for rules too.

Some thoughts about possible ways to integrate with Entity Metadata:

1.) Use Entity Metadata to provide Services integration to avoid duplicated code. This is what I've done in my github repo.
2.) Allow modules to optionally attach metadata to their resources + make it available to servers/via the API. This should be rather easy and not involve much changes - maybe it's even possible without any API changes at all (only additions). This is needed for modules to make really use of the metadata, in particular to achieve the improvements mentioned in the second point above.
3.) Furthermore we could improve the way Services describes data structures to be compatible with the way Entity metadata describes them - which is a bit different (but not much). This would ease integration between both modules and would make it totally compatible with Rules (as it also uses that way) + it would be consistent with the wsclient module. Establishing a unique way for describing data in Drupal makes much sense to me and would help to improve the DX.

I also think that if anyone has the time it would be good if work on this issue began as a contrib module of its own just like the REST Server and the Services OAuth module was prior to being incorporated in Services 3.x. That would enable a lot more flexible development of it.

Duplicating all resources based upon the entity API looks weird to me and would probable confuse most services users. Anyway, as outlined in #3 providing resources based upon the entity API is just the first step. But the further steps can only be achieved with API changes, so a services-addon module doesn't help here. E.g. it's not possible to utilize property information of a resource in a services rest formatter, as the API doesn't provide the formatter with that.

So "restws" tries to realize the ideas outlined in #3, thus it builds strongly upon the Entity API while it concentrates on providing RESTful services. If the approach proves to be successful, maybe service 4.x can pick it up for its RESTful stuff. Maybe it just smooths the way for some of its design decisions, or maybe not. We'll see.

You can find more thoughts about restws in my blog post.

ad #13:
As described in #12, making use of the entity API for resources is just the very first step, for which you can find the code on github (as you know). But as the decision of Services is to not rely upon the entity API for now, rolling patches for any architectural changes that would integrate much more deeply with the entity API is obviously pointless.

ad #15: Exactly.