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

[piranha]

the crossposting feature is only available through the web interface.

there was a discussion on why this is so, but i can't put my fingers on it right now, it's not in the metabug description.

however, you can institute multiposting from the client itself; i believe that's what was part of the discussion (which would also avoid loops).

[mark]

What piranha said.

I have nothing against making crossposting available to clients, it just isn't yet. Do you think that it's something that would be particularly useful for clients?

[brownbetty]

Well, lots of people post primarily from clients. It would be useful to *me*.

(Man, writing this comment from lynx, am now extra keen to help out accessibility w/ whatever I can. This could be friendlier.)

Useful

[dreamatdrew]

If for no other reason than it kills off some end-user time, hassle, and bandwidth, it's useful.
Also, a lot of the people I've talked to are touting the crossposting bit as one of the killer features of DW. Considering the inherent laziness of people (myself oh so definitely included), I can think of a lot of people who would love it if they can do it from an endpoint client as well as the web-based client...

[foxfirefey]

Another thing to think about is that people are going to want to do thinks like post by email and have it crosspost if they've set things up to crosspost by default.

[unixronin]

Well, I'd certainly find it useful, since I much prefer to use a standalone client rather than the web interface. In fact, I almost never compose posts originally using the web interface, if I have access to LogJam.
Since auto-crossposting is probably the most significant feature in making migration to Dreamwidth easier, it seems allowing clients to use it would be a benefit, and I don't see what harm it would do. (Of course, it would require careful testing, particularly of edit-and-resave.)

Re: LogJam porting question: prop_xpost_check

[unixronin]

Could you enlarge a little on that about "loops"? I'm finding myself unable to think of a looping scenario that would occur because a standalone client invoked auto-crosspost, that would not also happen if it was invoked via the web interface.

[zvi]

Another vote for it. I have difficulty figuring out who in the group "usually posts with client" AND "has crossposting enabled by default" would not want this functionality.

[mark]

Yeah, roger that. I'm convinced!

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

[allen]

I think that there's still a question of where the appropriate split between client and server is. I mean, to a certain extent crossposting is a client function: a client takes input from a user, maybe formats it up some, and then sends it to the appropriate server. If a user wants to crosspost that content, then the simplest solution to that in a client context would just be to have the client take that same input, connect to the second server, and do the crossposting itself. No need to configure crosspost accounts (and passwords) on the server at all. That would also mean that if the client author wanted to do nicer things, like make the crosspost messages customizable (before we get around to it), they could do that.

Now, of course, that approach would mean that the server would not keep track of those crossposts, so if the user came back and edited the original post via the web, then those changes wouldn't be propagated to the various crossposts. (You could actually get around that by exposing the crosspost mapping to the clients, so that they could register the crossposts with the server themselves.) It would also mean that the clients would have to duplicate the various server configurations, so if we find that IJ doesn't support some particular metadata, then that information would have to exist both in the DW code and in each client that does crossposting.

I guess what I'm saying is that, yes, of course, clients should be able to crosspost between DW and other services. But I also think that at least some of the support for that should be done on the client side. Now, whether that should be just that the client says, yes, crosspost this to my other accounts, or that it does all of the crossposting on its own, or something in between... Well, I'm less sure about that.

Now if only we had someone who was actually coding for a client to give an opinion on that... :)

[unixronin]

It would also mean that the clients would have to duplicate the various server configurations, so if we find that IJ doesn't support some particular metadata, then that information would have to exist both in the DW code and in each client that does crossposting.Precisely. Also, the DW servers "know" which tags depart from the LJ "standard" (I think that's principally just the cut and user tags), and therefore know which tags need to be mutated when crossposting.

The crosspost is done server-side when using the web client, is it not? I don't see why that should have to be different when using a non-web client.

[unixronin]

Oh, that just pointed out another minor LJ/DW difference to me ... behavior of the "quote" button. Please, DW dev guys, don't fall into LJ's behavior of making what the quote button does depend on what you've got selected for quoting. :)

(I ended up using a Greasemonkey script to make the quote button act consistently on LJ.)

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.

[zvi]

Can I just say that, as a user, you are assuming a split in my behavior (that I either use a client or the web interface) which I don't have, and which I suspect other users don't have.

That is to say, if I crosspost something and then decide it needs editing, I generally decide it needs editing because of the way the entry appears on the reading page or in my journal, and it's pretty common for me to edit the entry in the website interface, even if I originally posted with a client. (Sometimes, if I posted from another computer.)

My model holds true if the "client" I used to post was some other webservice, like e-mail or flicker or a delicious post, so I can see a fairly broad application.

[allen]

Erm, actually, I wasn't assuming anything about user behavior. I was completely forgetting that we even had users, and just thinking about the technical aspects. :)

No, really, the whole client support thing wasn't taken into account in the crossposter design. It will almost certainly be updated at some point, assuming that someone has the time to code it. There will be certain features that would be nice to have that won't get put in for technical reasons. (For instance, taking your example, it would be nice if you could actually edit your crossposts at LJ and have the changes propagate back to the post on DW, but unless LJ wants to update their code, it's not going to happen.) But hopefully it will be something that works for most cases.

[(Anonymous)]

Frankly, I'll be surprised if LJ revises their code to add crosspost support. There's little mileage in them doing so. And if other sites DO start adding crosspost support, it's going to increase the probability of loops, which will probably lead to the need for a formally defined crosspost protocol designed to prevent loops.

[silveradept]

After finding out a bit about the crossposter limitation, I'd like to register another vote of support for clients being able to engage the crossposter. Part of why I came over to DW is because I thought, assuming that I could log-in to the DW server and post using my client (Logjam), then the server would merrily propagate my post back to LJ, so that I wasn't abandoning people being able to see my posts if they stayed with LJ instead of jumping over.

Now, if I could just manage to do something else with DW that's unrelated to crossposting, I'd be a happy camper.