This is just a observation and tell me if this already exists and I just have not seen it.
Lately there has been a lot of talk about API's or modules that do nothing by them selves but are used by other modules. This to me makes sense when their is duplication across modules. Recently I was browsing the modules list and I noticed that their are a lot of module that change the format of a node or import nodes from another format. I am not a great module dev but I think their would be great benefit in a module probably a core module or contribute that becomes a core module that only handles this import, export, change of format.
For instance xml import export and PDF export, printer friendly page conversions could also be included but it does not really change the format of the content. Email this page functions could also be seen as format conversions but I think it would be best to keep that to a mail API or function.
I have also seen some new modules for 4.7 that are using XML. I have not work a great deal with XML but I do think a module that converts XML to arrays/nodes or arrays/nodes to xml would be useful to some developers, or something like that.
Does any body else agree with me.
Comments
interesting...
Hi nax,
interesting point(s).
I tend to agree about the development process, i.e. where there appears to be a lot of replication in energy and effort developing different modules to do something similar, or do the same thing slightly differently.
At the same time, I notice that, with the audio.module in particular, an explosion of audio related modules was nipped in the bud by Colin from Bryght, who saw the potential of doing precisely what you just said, i.e. he's more or less developing an "audio API" that other modules can tap into. in other words standardising how audio is handled in Drupal. not unlike how the Image.module evolved into a centralised handler for images...
There's no harm having loads of modules being contributed alongside strategic development along the lines of the audio.module, but, the challenge of developers knowing what other developers are working on etc. and collaborating is tricky. So that replication is probably unavoidable.
FWIW I think the next API or centralised module will be a mail related one..there are so many newsletter type modules or mail to a friend modules springing up that it's inevitable.
Off the top of my head, i can see a similar thing happening with Video/animation and Ajax..so contributed modules will get smaller in size or "lighter" over time and the core Drupal contributers might become more focussed on maintaining those core "APIs"(if that's the right term) rather than individual modules, which will become almost Snippet-like.
not sure if that contributes to your discussion point..but I thought I'd chip in my two cents.
crystal ball gazing aside..I think what you have pointed out is happening anyway as a natural progression and the sheer pace of development with Drupal I have noticed since joining up is truly staggering....
If you're thinking of developing an import/export API as you described, I recommend you check with some of the core developers in case that it isn't already a work in progress..
dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
I am not thinking about
I am not thinking about developing a module myself it was just a observation. But if some was to develop a module that handles format conversion or import/export there is a lot that could be considered.
You could look at the obvious. XML and PDF, but what about spread sheets or open office documents or what about export to image. If you had to report on the stats of drupal site a export to excel would make things easier. Or new users could find it easier to type out a page in open office or Word and import rather than using html area. Power point presentations could be imported as photo galleries.
In the end a person could take this as far as they want, it only depends on if it is useful to them and/or the community.
You've already investigated ...
... the existing Import/Export Module (link to my thoughts on it). A good effort, but it looks like it resembles the heady days when XML just meant you could make schemas up as you went along. ...
I've been wary of doing too much XML in Drupal so far due to the patchy/problematic support of an XML API in PHP4, BUT I also believe it's an important direction to move in for archiving and moving content about.
Export - as HTML!
My own directions have been towards exporting as Valid XHTML. I see no reason why a 'node' which is really just a web page should require a unique XML schema.
I've had success embedding the meta-information in a true XHTML page as METAs and LINK RELs, and a few DIV#id tags. All the required fields can be inserted into XHTML inline. (I think) And they are easily extracted again at the other end (easy with XSL anyway). My own 'Import' side of this can take arbitrary, existing HTML from (almost) anywhere. Haven't started looking at the Export code myself yet, it would resemplbe the 'printable' version.
Thus the transport 'schema' can stand on its own without Drupal and without any transformation neccessary.
Serializing additional properties
With reference to the terminology used by a naming schema like Thread Description Language all comments and stuff could be meaningfully archived/exported/tracked back also.
The XHTML itself is of course without skin or navigation chrome.
For email/notification/newsletter/subscription API, I'd suggest starting with an existing Email Term Vocabulary when choosing property and function names. I haven't found any of the newsletter modules suitable for my purpose, and I agree it would be easier for many things if there was a basic layer/object/API they could all be sharing.
XML...
There's a dozen PHP examples of this around the place, and core PHP is most of the way there now. I'd actually favour using the PEAR versions, but the Drupal codebase is (so far) done without reference to that great library.
Shared APIs
As to your major point about Shared APIs in general, I think it's a good move BUT the heart of an API is not just the availability of hooks, but the useful publication and documentation of them. APIs also, by their nature, need to have a lot more error-checking built in (assertions and stuff). This is not a handicap, I'm just saying...
A related discussion on using other modules functions as APIs
.dan.
http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Coding in progress
I am now developing an Import / Export API module, as my project with Drupal for the 2006 Google Summer of Code. The module is still in early development, but it's already heading in the direction that was discussed in this thread a few months ago. I didn't see this thread until now - good to see that other people have similar needs and hopes for this as I do!
The module will initially support XML and CSV as its formats.
Jeremy Epstein - GreenAsh
Jeremy Epstein - GreenAsh
Thanks for the ping
Old thread, but glad you popped it!
FYI, I dunno if you saw my efforts with ImportHTML
It's 4.6 only so far, and I never got around to adding support for custom fields/metadata, but I'd like to chip in with whatever you come up with on this project. I like the pipeline method, described in detail in the helpfile so I'd be interested in what you are planning with an API to help.
I'm thinking of getting it to 4.7 sometime, I've got a better handle on the formsAPI than I did a few months back, so I imagine I can remake the directory browser (that was the big obsticle)
I'll go have a look at the wiki now...
.dan.
http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards