New importer to work with any retrieval library and interface with any module
| Project: | Drupal Contact List Importer |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | by design |
Jump to:
I gave your module a test-run but discovered that the cl-grabber library that this module includes is no longer working and is unmaintained. So I wanted the ability to use other retrieval libraries. I also wanted to more easily interface with other modules, not just Invite module.
So I started writing a patch, but I quickly discovered that there are some fundamental architectural issues with DCL Importer that would make my desire for easier external integration difficult.
So I started from scratch. The result of my work so far is this module here:
http://drupal.org/project/contact_importer
The module is currently fully functional, but needs further in-production testing before a real release can be made.
I am offering an invitation if you would like to collaborate on further development.
#1
it appears the contact_importer module is no longer maintained. the dcl_importer has been rewritten completely for D6.
#2
Not true. There is a D6 release.
http://drupal.org/project/contact_importer
If DCL Importer is not yet production ready, you might consider writing an engine for contact importer for OpenInviter. It would be < 200 hundred lines of code, which you would basically copy from the work you've already written.
#3
Heh, well there wasn't a D6 release when I checked yesterday :). I believe the goals of contact_importer and the dcl_importer are the same though. How do you feel about also having some additional code to allow the contact importer to be integrated with tools like the invite and user relationship modules?
#4
Yes definitely! It would be much more useful if it had direct integration with other modules.
#5
This would be great if you guys could join together. Especially help contact_importer to fit in well with invite and user_relationship... and if possible also one of the forward or send modules (share one node). ... this is a tool that Drupal really needs.
Not easy for me cos I am not a programmer, but I will be very happy to do some testing and report back :):)
JJ
#6
I agree that they should be combined into one project. Looking at the usage it seems that they should probably merge into the dcl_importer, but i'm open to arguments for the other way :). Right now most of the UI code has been stripped out of the dcl_importer module into "connector" modules for friendlist and invite module. It's still definitely not in a place to be used in production though.
I'd like to ultimately see it be able to hook in multiple retrieval libraries at the same time, and be able to select which services you'd like which retrieval library to use. This way you could use, say, openinviter for gmail and then octazen for the rest, or something like that. It's already possible to configure openinviter in dcl_importer to only import from certain services, but there's no support yet for multiple retrieval libraries.
#7
Upgrading this to 6.x issue. I'm going to start adding support in for multiple libraries, I'll likely base it off of your work on the contact_importer module so that they're somewhat compatible.
#8
Just to clarify, contact_importer already does support multiple libraries. To add a library to contact_importer will just require copying the octazen_engine folder:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/contact_imp...
And editing the module in there. It would mostly just be changing the form validation function to use the other engine.
#9
The dcl_importer does other things that the contact_importer doesn't, which was why I suggested merging them instead of simply dropping the dcl module. Anyway, the framework was redesigned to support multiple importers a couple weeks ago and support for octazen in particular can be followed here: #524838: Add other libraries such as Octazen (basically I don't want to pay for octazen just to build in support for it, since I don't plan on using it myself).
#10
#11
subscribing