---from hadsie: ---
The possibility of running multiple engines simultaneously. One of my goals on dcl was to eventually provide support for oauth and services that use oauth like gmail, for example. Since only one engine can be used at a time, if I wrote an engine that supported oauth services and used that, I would no longer have access to providers that don't support that protocol.
My idea for how this would work (and it was implemented in DCL though I never had more than one engine to test it on) would be to set a weight for each engine. Each engine also defines which services it provides. If an engine (say an oauth engine) supports gmail and has a lower weight then another engine that also supports gmail, then the submit callback for the lower weighted engine would be used for gmail and the second engine would be ignored. One problem that comes to my mind immediately is that the input form for each of the different engines would be different, since an oauth module would not have a password field, for example.
---from dalin: ---
This sounds like a great idea. Especially since at any given time an engine is broken for at least one major email provider (OpenInviter is currently broken for Yahoo and AOL). I don't think you'd need to do anything with weights. Rather I think we could integrate it in with how you choose which email providers you want to support: There could be a new admin tab (which would replace the existing OpenInviter tab). It would list all the providers from all engines. For each provider there would be a select box for the admin to choose which engine to use, or to disable completely. Then on the end-user side of things, make it a multi-step process. First the user selects which provider to import from. Then the appropriate fields are displayed via some simple JavaScript (You'd basically load all the necessary forms, but only display the one appropriate for the email provider).
---from hadsie: ---
This could be done using ahah forms. I had something in place for this on dcl but never used it because it was unnecessary with support for only one engine :)
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | contact_importer_672150.diff | 99.86 KB | dalin |
| #2 | contact_importer_672150.diff | 77.2 KB | dalin |
| #1 | contact_importer_672150.diff | 61.86 KB | dalin |
Comments
Comment #1
dalinHoly crap this turned out to be much further reaching than I thought. This patch is my work so far (must be > 10hrs) and is just the back-end. The front-end is completely broken. But I figured better not start on that till the architecture is finalized.
The back-end is pretty solid. The 'engines and providers' tab is pretty jam-packed but I couldn't think of a better UI for that.
The good news is that this whole thing greatly simplifies the engine modules. OpenInviter is down to 300 lines.
Comment #2
dalinHere is my second patch. We've come a lot further. We now have the first step of the user-facing form working. And we have favicons that are cached locally.
This is definitely going to require opening up a 2.0 branch.
Comment #3
dalinOk I have the whole kit and kaboodle working. Next up is to create a 2.0 branch.
Comment #4
dalinThere is now a 2.x branch with this code. Any new problems with this should get a new ticket.