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

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

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

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

[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!