Jumping in with questions and answers

[pauamma]

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?)

Comments

[jeshyr]

Ohhh, that's a very cool idea!! I've been hesitant about answering stuff because I'm still very newbie-ish (it took me an hour to set up a 'map' function yesterday for a one line patch) and I have weird splinter-knowledge. It's good to have a "safe" spot where I know somebody with more experience will come and correct me if needs be!

Weird thing I wonder about: What does "stc" stand for in the directory naming system? There are two (I think? at least one!) directory called "stc" in the code and I don't know what they're for. I'm trying to figure out the function of the directories for myself and documenting in http://wiki.dwscoalition.org/notes/Main_development_folder but there are so many I don't know!

[denise]

Not positive (the true answer may be lost to time) but I think it's 'static'.

[sophie]

That would make sense! I had wondered the same thing.

[edit: I took a look at the LiveJournal repo. http://code.livejournal.org/trac/livejournal/changeset/5208/trunk/htdocs is the appropriate changeset where the htdocs/stc directory started on 13th July 2005, and the description is "Move floating .css file(s) to a more appropriate place."

Based on that, yeah, I'd say it was likely that "stc" means "static".]

[foxfirefey]

Haha, I've always wondered that one too.

[skakri]

I have a question. Hypothetically speaking - could external site (cross-posting) controller be modified to support Twitter / other social platform? How should I implement that, as I'd have to have a separate table for user id => auth_hash. I'm currently learning how to get/parse/use data via Perl (previously I've used only PHP/AWK/bash for my scripting purposes; If I have a question about some controller, I mostly use

find /home/dw/ -type f | xargs grep 'what was I looking for' | less

).

Another one - if I define a "beta feature", could I somehow use

 LJ::BetaFeatures->user_in_beta( $u => "featurename" );

in my .tt template to conditionally load needed JS assets (I like the idea about "real time web" - as I've used to node.js and socket.io, I'd like to try to implement real time comments)?

[denise]

We have a bug open to add Twitter crossposting (and Facebook, and Wordpress, and Movable Type, and and etc) -- the issue with each of them is that you have to a) implement the remote site's posting protocol and b) work out how it would map to DW. (For instance with Twitter, figuring out how you would handle the metadata like current mood/music, figuring out what to do if the post is over 140 characters, etc.) So yes, it's possible! It would go into cgi-bin/DW/External/XPostProtocol and get hooked in somewhere (I'm not sure where). (And if you get it working, give us the patch. *G*)

I don't know TT or how to work the beta features, so I'll pass on that!

[pauamma]

You can't call Perl code directly from templates, so you have 2 solutions, I think:
- have your controller pass variables to your template indicating which beta features the user has turned on. Then you can do something like [% IF uaerhasbeta.featurename %] [% dw.need_res( 'js/featurename.js' ) %] [% ENDIF %] (syntax not guaranteed)
- write a TT plugin (see cgi-bin/DW/Template/Plugin.pm and cgi-bin/DW/Template/Plugin/*) (being vague here, because I'm unsure of my footing)

Which is best depends on how many templates would need to test for beta features and whether this change is strictly localized to the templates, or if it affects the controllers as well.

[exor674]

or in this case, we'd extend the existing plugin. We really do not need multiple plugins for just one purpose.

[pauamma]

*nod* I wasn't sure whether we needed/wanted this, so thought it best to keep any plugin work separate.

[fu]

I like the first one! It's very simple, and is also easiest to find/remove later once something is out of beta.

[skakri]

So basically, .tt can access user information/settings? That sounds awesome, I'll try to implement "beta feature" detection in to my template.

[pauamma]

They can access anything the controller passes them. You would still have to add code to the controller to retrieve that info and pass it to the template.

[fu]

The main thing you need to do to implement crossposting is to create another subclass of cgi-bin/DW/External/XPostProtocol.pm. 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/LJXMLRPC.pm, 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/XPostProtocol.pm, 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.

[exor674]

Also.

Hypothetically speaking - could external site (cross-posting) controller be modified to support Twitter / other social platform?

I am actually ( in my oh so copious ) free time working on at least the bit to auth a twitter account, just in case you want to avoid duplicating work.

[allen]

Re crossposting to Twitter: what fu said. Use DW::External::Account to store the connection/authentication information, then extend DW::External::XPostProtocol to do the actual implementation. Especially look at overriding XPostProtocol->options() to add in additional, protocol-specific fields (LJXMLRPC does this; look at it for an example).

I have a not-quite-working version of the Atom crossposter that I could upload if you want to see an example of adding a new protocol. That I remember, most of the configuration stuff works; it's just the crosspost itself that doesn't.

I can also give you a walkthrough of how I've done crossposting development in the past (what workers to start, etc.) if you'd like.

[pauamma]

I can also give you a walkthrough of how I've done crossposting development in the past (what workers to start, etc.) if you'd like.

If you do, could you paste it here? It'll go into one of the wiki pages on workers I'm contemplating.

[skakri]

That would be just great. The API in question uses "User approvement -> hash, hash -> action" model. So I could authorize user, store hash and push post information (title and url) to their API.

Basically, I'd just like to try to dive in, "how stuff works", so far, I've only adjusted DeadJournal plug to xpost to ancient LJ page.

So yes, I'd really like to see the code you're working on. That would help me a lot!

[allen]

http://bugs.dwscoalition.org/attachment.cgi?id=5498&action=edit

That should be the attachment itself. Or just go to http://bugs.dwscoalition.org/show_bug.cgi?id=2296 and get it from there.

As I said before, the Atom code doesn't work, but it should work as a template. Oh, and there seems to be a bug that I just noticed where if you go back and view Details on a non-LJXMLRPC account, you still see the LJXMLRPC options.

So the way I usually work on crossposter issues is to open up three windows, go to $LJHOME/bin/worker, and start up xpost, esn-process-sub, and process-esn. Oh, and go into Manage Account, and under Notifications, enable notifications on successful crosspost attempts. Makes troubleshooting easier.

In general, any time you update any crossposter code in DW/External you'll need to restart the xpost worker. You shouldn't need to restart the esn workers unless you're actually working on the notification code.

Some errors that aren't caught by the xpost worker end up in the sch_error table; if you are having mysterious failures, it's worth checking there.

I think that's most of the special crossposter development notes, other than just "here's the code, look at how external accounts are created and configured in externalaccount.bml, look at DW/Worker/XPostWorker to see how the actual crossposting code is called by The Schwartz, and hope that you don't have to deal with the part in between where you actually do the post and the crosspost job gets created." :)

[pauamma]

So the way I usually work on crossposter issues is to open up three windows, go to $LJHOME/bin/worker, and start up xpost, esn-process-sub, and process-esn.

Why both esn-process-sub and process-esn? Looking at the code, process-esn handles all 4 stages, including the esn-process-sub one?

[allen]

Why both esn-process-sub and process-esn?

Habit? :)

[jeshyr]

How do you start individual bits like that anyway?I 've only got as far as "worker-manager --debug"

[pauamma]

Pasting from the wiki page about that topic I'm working on:

=== Individually ===

You can also start individual workers from the shell prompt, by typing:

<syntaxhighlight lang="bash">$LJHOME/bin/worker/(worker-name)</syntaxhighlight>

Most workers accept the <code>-v</code> or <code>--verbose</code> flag to request extra debugging output and stay in the foreground when started from the shell prompt, so ^C should work to kill them.

[afuna]

If this works, I'll try to make it a regular feature of this community. (How often should it happen?)

Hm, maybe once a month, or once every two weeks?

[jazzyjj]

I love this idea, and am glad it now seems to be implemented. Unfortunately, I just have not had near the amount of time in recent years to devote to these things as I'd of liked to. But I *think* that's about to change. I have very chatty neighbors here in my building, one in particular. Luckily though they are all super nice and friendly and all that. But I've made it my goal to get into this programming stuff and more advanced uses for all my awesome assistive technology. I know next to nothing about programming, so these question-and-answer threads will really help me out. Hopefully more of these will be popping up.

[pauamma]

I try to start one nearish the end of every month.