Anyone working with this? Using SOAP::Lite, or Net::Amazon, or one of the interfaces?
Many ecommerce and affiliate sites are making feeds available, and the trick is to import them, without violating TOS or causing server overloads. I've been trying to make an interface class for Links, specifically for Amazon via Net::Amazon, but generalize it to almost any other XML type feed.
Pooling efforts, sharing problems, etc would be helpful.
What I want to end up with is a Link object, that can take the returned XML object, and map the fields into the appropriate fields. On an advanced level, it could pick out missing fields, and flag them for the Admin to evaluate (as if in the XML object changes).
Set up of the plugin would require mapping database fields to the response object, and there would be one mapping per plugin, affiliate site, or xmle feed (rather than just "one" mapping).
There are hacks that can be done, on a case by case basis, but what is needed is a a new module, Plugins::XML or Plugins::WSDL (or whatever it ends up as), that other plugins or utilities can call.
It seems putting them in the Plugins directory would be more portable, in general, and it would override any system similar files because the script libs come ahead of the Perl libs (I'm pretty sure).
This is primarily for INPUT -- product feeds, books, dvds, etc (where as the WS4LSQL is primarily for output, it seems)
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
Many ecommerce and affiliate sites are making feeds available, and the trick is to import them, without violating TOS or causing server overloads. I've been trying to make an interface class for Links, specifically for Amazon via Net::Amazon, but generalize it to almost any other XML type feed.
Pooling efforts, sharing problems, etc would be helpful.
What I want to end up with is a Link object, that can take the returned XML object, and map the fields into the appropriate fields. On an advanced level, it could pick out missing fields, and flag them for the Admin to evaluate (as if in the XML object changes).
Set up of the plugin would require mapping database fields to the response object, and there would be one mapping per plugin, affiliate site, or xmle feed (rather than just "one" mapping).
There are hacks that can be done, on a case by case basis, but what is needed is a a new module, Plugins::XML or Plugins::WSDL (or whatever it ends up as), that other plugins or utilities can call.
It seems putting them in the Plugins directory would be more portable, in general, and it would override any system similar files because the script libs come ahead of the Perl libs (I'm pretty sure).
This is primarily for INPUT -- product feeds, books, dvds, etc (where as the WS4LSQL is primarily for output, it seems)
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
WSDL, XML, SOAP, etc