API like Uniform for Module-2-Module communication
Hi
First, excuse me if theres already some solution for.
I've surfed drupal.org and also the groups but didn't find something...
What I've to do is building a "stack" like Acquia but with advanced functionality.
For this I'll need to grab some already existing Modules and change some of their functions to work "cleaner" with other or mine, too. Because of this it would make updating Core and also Modules a horrobale job I'm looking for a standardize solution to let Modules communicate with each other without bigger modifying.
I've thought of building some extra features into the core.
The most important ones should be:
- A new hook by using Modules can define IO-Streams for serving and expecting data
- Enhancing the Module-Management to check expected IO-Streams before updating Modules to newer versions
This hasn't to happen by a hook (or hooks), I also imagine to create moudle.io files in XML for that!!!!
For sure this would be an API which has to get maintained.
This would be a job I surely could and would do!
E.g. by a Group or may be as a project...
Please let me know what you're thinking about and if you guys would help me with figuring out an API Schema.
Kind regards
Uhu
development greatly appreceated
hi uhu,
development of this feature would be greatly appreceated here!
let's contact and see, what we can do. best, alex.
--
@ °
/ datengarten °
I mean...
Hi
What I mean should be a Module like "Services" http://drupal.org/project/services
But just only for Drupal internal data-exchange.
Why should someone use this ?!?!?
Imagine the case, that my "Module1" has to work with some data from "Module2". Because of "Module2" serves no API I´ve to do handicrafts on my own Module...
Once a Module-Developer changes one or more vars my Module may crash!
If there would be a Master-API, data could be transfered between Modules witout knowing closer!
You just have to know the API like you know the DB-Interface-Functions for example...
Do you unterstand what I´m trying to say??
regards
Uhu
If I understand you correctly...
If I understand you correctly you want to provide a standardized way to create internal middleware modules to interface with 3:rd party modules that are ill-written or doesn't provide an API?
I think that it's a better idéa to submit a patch to the module that one want's to interface with, so that it gets a proper interface. With regards to safeguarding against changes in a existing module API, that would require versioning of the "Master-API" so that module A can keep interfacing with module B in legacy mode, while module C can communicate using the new api version. Added to this are the cases where not only the API changes, but also behaviour. This will result in a lot of legacy code hanging around to.
My question is if this is really worth it? I'm not saying that it definitely not worth to do this, but it has to be brought into question. Will it ever be a really good replacement for just plain testing your modules with new versions of 3rd party modules and making the necessary changes? Or will it just add bloat/complexity to drupal?
If I follow correctly
While I do agree with Hugo I could see a need to have a standard may to secure communication between modules on different sites either on the same server (via sub-sites) or across domains. Providing the API for an existing community module would be a great start. However based on my experience with organizations and the enterprise (no not the starship) there is a strong need to provide granular security.
For example I could see the need to issue certificates or unique keys for specific requests, especially if the request inserts, updates, or deletes data or media to and from multiple Drupal sites automatically. Also having an interface to grant access to specific API actions would be useful as well for individual identities or keys.
I am sure a developer could setup security both on the server in Apache or via routers on the network to allow only a specific IP range. But having a security layer within Drupal that is homogenized for this type of communication that any module could check against either has a validation hook or a specific set of security APIs would be useful.
That's my thoughts on the subject, security is sourly lacking in Drupal and more so, the usability of many of the community module makes it even harder to use. Yeah I know this sounds like whining, so I hope to contribute and help fix that. :)
Actually this conversion is exactly what I mean: http://groups.drupal.org/node/17578