Multiple Server settings and connections and Resource Type

I plan to implement some of the items in #2 starting tomorrow..

• need the ability to select an active office, set their orgID so i can identify their properties to allow for enhancement(s) / and views integration/filtering.
• need the ability to pull the active agents for the selected office so that i can pull listings to show on an 'agent' page via a node reference.
• need the ability to assign permissions to a agent/user to allow them to enhance their 'own' properties
• need the ability to display open houses for properties and agents through a node reference

This is functionality that i'm porting over from my my recently scrapped drupal rets module that i was working on. However, PIRETS leapfrogged me ahead quite a ways in a few areas I was putting off / procrastinating on! For that i'm thankful and plan to contribute back and enhance as much as i possibly can.

vasike, you're the second person so far to suggest the ability to connect to multiple sources. I'll take it under advisement, though I'm not really sure the best way to go about implementing it.

camidoo, RETS sources in general seem to have fields for ID numbers for the agent and agency representing a property. You should be able to enable them as normal and then use Views to filter by that field fairly easily.

It's cool to see you're inspired, but keep in mind the primary function of PIRETS is to fetch and store RETS property listings. If you plan on adding functionality beyond that, it would probably go better in your own module than as patches to PIRETS. I'm not interested in expanding PIRETS' functionality very far beyond what it already does. Just want to warn you before you go through all the work of hacking PIRETS and making patches that I refuse to accept…

In the near future, I'll probably add a "Development" page to PIRETS.info with some tips and pointers for those who want to hack PIRETS or write modules which integrate with it.

Would it be possible to implement this feature as optional sub-module that ships with this module?

If it would be possible, a common practice in contrib is to grant CVS access to co-maintainers, but have a gentlemen agreement so that co-maintainers are only granted to commit changes for certain stuff.

camidoo just told me that he thought about applying for drupal.org CVS access, to "fork" this module, basically just to be able to introduce a multiple connection feature (whatever that means, note: I'm not using this module, nor do I have any idea what it does).

This sounds like his "new" module would do exactly the same in the end, just supporting some variety in connections and perhaps other small tweaks that would probably also benefit this module.

It would be great if you guys could find a solution within this module, and most importantly, join forces. :) Especially, since it seems that this module is doing some fairly special stuff.

Thought I'd throw my 're-write' of PIRETS up here for review, Originally I had planned to do this as patches to PIRETS and help further the project along, however after being shot down I just went ahead and re-wrote the module and had intended to release it as a separate module all together. After giving it some thought, and discussing the situation in IRC with sun, I'd like to make a second effort to see about getting some of my enhancements and tweaks, included into PIRETS, as I'd rather not fork a module, nor would I like to add to the already plethora of duplicate modules and code that already exist.

In this rewrite the following has been done:

• Switched the connection 'layer' out to phRETS. This completely abstracts the the RETS connection layer. PIRETS original connection layer is hard coded to work with resources of 'Property' only. Additionally, in favor of complete abstraction all cache calls and any 'drupal' calls were abstracted from the connection class and moved to the module file so that swapping out the connection layer with some other library, or custom connector can be facilitated in a cleaner way.
• Added additional support for: Open Houses, Agents, and Offices. The only 'standard' type that was left out is the support for Tours, which can be easily added if requested or needed.
• Added the ability to create multiple connections. Multiple connections can now be added, and configured to work with existing class definitions. Meaning, you can now add an additional connection, setup the 'Property' type, set it's class, and map that classes' fields to existing cck_fields used by other connections for the same type. (not sure how clear that is!)
• Added the ability to define cck field names and cck field labels.

Most of these issues are deal breakers, keeping me from using PIRETS, which is why the changes were made. I'd like nothing more than to move PIRETS along. Barring that, I don't think there's any other way to contribute the functional enhancements I've made back to the community without 'forking' PIRETS and releasing it as separate module.

subscribing

some updates.. new file

PIRETS is the culmination of solutions of the needs of our clients. None of our previous real estate clients needed multiple connections or agent listings, and therefore PIRETS doesn't support these things - though I would consider those, as well as most of the other things in #5, to be features which could be added to PIRETS without diluting its vision. However, given these are rather large tasks, they probably won't be implemented unless either the code is submitted by others as a nice clean patch, or… well, a (paying) client needs the feature.

All that being said, camidoo, do you still consider this a fork?! I'm looking at this code and I hardly recognize it! It's to the extent where this is far more your code than mine. Therefore, I would totally not object if you were to add this to Drupal.org as your own project.

Others may disagree as to its forkiness. Still others really get their briefs in a nice, tight wad about two different modules being in the system that do similar things, but I find life to be more pleasant if you ignore these people (PIRETS does similar things to the MLS module). One thing to watch out for, though, is that, generally speaking, external libraries and such aren't permitted on D.o - so you'll have to ask people to download and install the phRets file separately, similar to how people must do it with the various WYSIWYG editor modules.

Thanks Garrett, I think you're right and I'm going to go ahead and release it as a separate module, I was really concerned about releasing a module that was similar in functionality. When I do release it, after cvs access is granted, I'll ensure to credit PIRETS and yourself as the inspiration and the basis for the module. Additionally, I'll put a link back to PIRETS as an alternative solution to the one I release.

I really appreciate your hard work and that you released the PIRETS module as it has saved me about a week or two of development time in the end, and would never want to take credit from the work that you've done. I'll continue to advocate PIRETS and help out where I can with patches and support, after adding the features I have to this new module I've become pretty familiar with the PIRETS code base, figure it's the least I can do.

-camidoo