LogJam porting question: prop_xpost_check

[unixronin]

I'm working on an update to Evan Martin's LogJam client to support the metadata and tag changes on Dreamwidth. I have it mostly ready to go, apart from a few site-specific issues like the cut and user tags, but I'm running into a problem with prop_xpost_check. When I submit a test post that attempts to set the prop_xpost_check property, the submission fails with an 'invalid metadata' error. Is the auto-crossposting feature intended to be usable by remote clients, or is it available only when submitting through the web interface?

Comments

Re: LogJam porting question: prop_xpost_check

[allen]

The loop issue would depend on how the crosspost gets initiated. If the client does what it sounds like you want it to do--that is, gets a list of the available accounts for crossposting, selects the ones configured for default crosspost, and then sends back a postevent with crosspost enabled for those accounts--then there isn't a problem. DW gets the postevent, makes the new entry, and then sends out postevents to the other servers. obviously not telling them to do any crossposting themselves.

The problem would come up if, instead of making the client explicitly request a crosspost, you instead just declared that posts coming in from clients and email are assumed to want the default crossposting behavior. Then you could run into a situation where account 1 was set up to automatically crosspost to account 2, and account 2 was set up to automatically crosspost to account 1. Then you'd have a loop. (I suppose you could get out of that by putting in an explicit crosspost disable that happens on crosspost, but I'm not really sure that's a better solution.)

Re: LogJam porting question: prop_xpost_check

[unixronin]

Yes, I thought of that problem. However, I don't see why that type of loop would not occur when posting with the web interface too.

I would think the only way to avoid that problem, if multiple crosspost-enabled journal sites exist, is to have the server be able to recognize when it receives a crosspost request for an article it has just sent out as a crosspost itself, and stop the loop. Neither a standalone client nor the web client has the ability to detect and stop a crosspost loop, but the server does.

Re: LogJam porting question: prop_xpost_check

[allen]

However, I don't see why that type of loop would not occur when posting with the web interface too.

Because the web interface is the part that initiates the crossposting, but the crossposts themselves are done via the XML-RPC interface. So when a crosspost is done, it skips the web interface, thus guaranteeing that no additional crossposts will happen.

...That really isn't very clear, is it? Think of it this way: a running Dreamwidth instance is both a server and client. It's a server in that it can it can create and serve up journal entries via a standard protocol. It's a client in that it can display those entries in a nice format to the user, and can also put up a web form for posting new entries, and then translate the submitted form into a properly formed protocol request to send to the server.

So the crossposter is actually implemented in the client part of Dreamwidth, not the server part. Which is why if you use a different client, be it an external standalone client or just a different interface (like the email gateway), it doesn't function.