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

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