pauamma: Cartooney crab holding drink (Default)
Res facta quae tamen fingi potuit ([personal profile] pauamma) wrote in [site community profile] dw_dev_training2011-09-21 12:11 pm
Entry tags:

Jumping in with questions and answers

I just came across To Answer, Or Not To Answer. The gist of it is: someone asked "Should I answer a perl question when I'm not sure of the answer or when I can only answer part of the question?" and got overwhelming "yes" answers (and very good suggestions on how to handle uncertainty), because even if your answer doesn't help the person asking, researching your answer (and thinking about the question) may well help you. So as an experiment, I'd like to try something similar in this entry:

- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)
- You may also answer any question, using the guidelines given in the discussion I linked to above.

If this works, I'll try to make it a regular feature of this community. (How often should it happen?)
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)

[personal profile] fu 2011-09-22 02:45 am (UTC)(link)
The main thing you need to do to implement crossposting is to create another subclass of cgi-bin/DW/External/ You can get the list of methods that the subclass needs to implement from that file as well; it's in the section called

# instance methods for subclasses.

We currently only have one for LJ-based sites -- cgi-bin/DW/External/XPostProtocol/, you can use that to see what (in general) you need to handle in each.

Then, so that it will be registered as a crosspost handler, and show up in the dropdown when you're setting up a crosspost account, add the class to the protocols hash in cgi-bin/DW/External/, like it is here:

my %protocols;
eval { $protocols{"lj"} = DW::External::XPostProtocol::LJXMLRPC->new; };

I'd probably start really simple first! Hardcode authentication while you figure out how to use the other site's protocol, and then when that's working, figure out the problem of storing the authentication.

Why not continue to use the externalaccount table, btw? The field says password, but it's always just the hashed password which can be used as an authentication token; it's not a huge stretch to use it for other auth schemes.