First, because it's a question that I don't want overlooked at the end of the rest of the text: I forgot to change my InsaneJournal syndication settings last night to not post complete entries to the syndicated feed of my IJ account over at LJ (intended as a temporary change just for the day). I tried to take care of that just now but cannot find the page on which to make the change. Er ... can anyone help me out here?
Anyhow, on to what I was thinking about just before that:
Huh. The modification I made to my client last night doesn't agree with CrazyLife for some reason (which is why my QotD didn't post there at 5:25 this morning -- I just posted it manually using the previous version of the client (glad I renamed it instead of just writing over it!) after noticing that my most recent entry had failed there. I wonder what the problem is. (It's reported as "problems logging in", which is odd considering that the edit I made was not in the login module. The error-reporting may be off.)
Because I've been too lazy yet to hack Clive (the client I use) to crosspost automagically (I do have a plan[*] for that, but ...) I've got nine copies of the executable instead, each aimed at a different site, and I invoke them each from within a foreach() loop (I'm a csh/tcsh users). As a side effect, this made it easy to strip LJ out of the list of sites to crosspost to today: all I had to do was 'mv ljclive ljclive.real ; cp dummy ljclive' (dummy is a program that does nothing -- void main(){} -- that I've found surprisingly useful over the years). In order to automate the trick where this morning's quote-of-the-day was posted to LJ as a fake cut-tag linking to the InsaneJournal copy, I had to make a wee change to the InsaneJournal client so that instead of reporting success with the message, "Successfuly posted item [ITEMID] to InsaneJournal," it would report the URL of the entry it had just posted. (When I get a round tuit, I'll add a command-line switch to choose at run time between reporting the itemid or the URL on success.) Wanting to keep my computing environment a wee bit more tidy than my house (uh, actually, I fail in both places, but never mind), I went ahead and recompiled all the clients to have their code in sync. Hence the CrazyLife glitch which I'll need to debug later.
Of course, I completely forgot the reminder in the motd here, pointing out that my ISP upgraded the host I usually log in on to a newer version of NetBSD than the other hosts available to users and that programs compiled on this one might not work on the others ... and that cron jobs run on one of the other hosts. Luckily, despite my attempts to the contrary, I was still awake when the QotD script ran, eventually noticed that it was stuck, and recompiled the nine clients on the right computer and ran the script again by hand. (Which is why today's QotD showed up at 5:55 instead of 5:25.) I did test things beforehand, of course, but, you guessed it, I tested them on the wrong machine. I blame poor sleep. (Why yes, that is an awfully convenient excuse, but that's my story and I'm sticking to it.)
So: glitchitude. But relatively minor stuff, annoying but easily worked around until I figure out how to fix it properly, or in the case of the compiled-in-the-wrong-place problem, trivially repaired. But not the completely smooth operation I'd hoped today would appear to be.
And I thought I had a similar problem with CommieJournal, but apparently that entire site is down today for maintenance/upgrade/something. (Maybe not the best timing for that, but if something broke and they had to fix it, oh well.) I'll try to remember not to overwrite the text files containing today's entries as I compose each next entry, to make it easier to post 'em all to CommieJournal once it comes back up.
And the Blurty client is reporting failure, but my entries are showing up there. Hmm.
Okay, now to go take care of those errands ...
[*] Actually three different plans. My question a few days ago about whether anybody else still uses Clive was to help me decide which plan to use.
Questions -
What will the end user get? What will they need to put in? I've been trying a bunch of different clients and not been too happy with many. Mostly it's hard to swap between clients or do one-push crossposting.
Plus, some folks have issues with the retention of user info (login, password). I'm thinking a simple login management screen if it's stored on the user's computer; you can check off where it's posting, heck, even if one is posting a sample and link or a full entry per account.
If this is a hosted solution, a widget that lets the user maintain their own login information in an xml file on their own computer so it's never stored on the server? I don't know enough about it from you descriptions to give suggestions on how to make it user friendly and usable for multi posters.
But I look forward to watching the development. :)
Re: Questions -
1) Typeand it'll fire up the editor you configured it to use and then log in and post the entry you typed in the editor ... or
2) Compose your entry separately and store it in a file, then typeand it'll log in and post the contents of the input file. I nearly always do it this way.
(There are more options you can use, and -i and -s are really optional, but I wanted to show a 'typical case' example.)
I haven't tried to compile it under Cygwin yet, but it can be made to work under Linux and Unix and I think MacOS (which these days is Unix under the hood anyhow); in any event, you run it from a command line ("terminal window" or "console window" or on a Linux box not running X, just the console itself ... even a dumb terminal dialed in via modem will work).
So right there, a lot of people are going to go, "Command line? Eww." I imagine one could write a cute GUI shell around it, but it'd probably be easier just to download one of the popular GUI clients. Me, I wanted three things: to use the editor of my choice; to be able to pipe text into it or read from a file; and to be able to use it no matter which computer I'm sitting at without having to install and configure it on every single machine. Since it's a command-line app, I can just telnet or ssh from any computer I find, to a computer where I've already installed it (such as at my shell-and-mail ISP[*] or my main Linux box at home).
You're supposed to be able to store the username and password in a config file in your home directory on the machine where you run it instead of putting them on the command line each time. I don't remember offhand whether it'll prompt for them if you do neither. In any case, the password doesn't normally get sent off of the machine on which Clive is running[**].
So that's the tool I'm starting from. With that, in addition to normal posting of entries, I was able to write a shell script to pluck the first entry from a file containing a queue of them and post it as my quote of the day (and, of course, set up that script as a cron job); and write a Procmail recipe that pipes certain text messages from my cell phone into Clive to be posted (which means 1: not relying on the site I'm posting to to support SMS posts directly at my account level or at all, and 2: the ability to crosspost the SMS entries).
Next, the crossposting hacks.
[*] I buy shell access, an email address, and some disk space (and web space) from one ISP, and my broadband connection from another.
[**] IIRC, it can be forced to do plaintext authentication (where it sends the password to the server in the clear), but that's neither the default nor recommended.
Doh!
Re: Questions -
This is, admittedly, cumbersome even for me. It should be a shell script that works as a wrapper for Clive. But I ran into problems with the multiple layers of quoting for subject headers with spaces in them, and back-burnered that script. Of course, if I get around to hacking crossposting into Clive itself first, I won't need to debug that shell script.
And you can see here that I've done something rather dangerous, and am relying on something I got lucky with (using the same password at each site, and getting the same username at each site, respectively). Building crossposting support into Clive itself, if anybody but me will use it, needs to be done in a way that doesn't rely on those two things.
As to where I've gotten so far, changing one line to make it spit out the URL of the entry it just posted instead of the itemid assigned by the server (which is not the same number that appears inside the URL), meant that the temporary version of my 'postqotd' shell script could take the output of the post-to-IJ copy of Clive, run it through sed to turn it into the fake-cut-tag entry to post to LJ, and pipe that into the post-to-LJ copy of Clive. (And writing this paragraph has just reminded me that I forgot to switch it back to the regular version of 'postqotd'. Whoopsie!)
My to-do list for Clive is:
My ideas for how to better support crossposting are (so far): add a command-line option to select the journalling site to post to (which means using it the same way I do now, but only having to maintain a single executable that posts to all the different sites) or make it read a list of sites from the config file (or a second, just for crossposting, config file). For the first of those I've been mulling over two versions: either put the whole URL of the hosting site on the command line, or put the name (or user-supplied abbreviation) on the command line and have the program look up the URL that goes with that name in the config file.
(That is, whether to have the user add "-S www.insanejournal.com" to the command, or to have hir add "-S ij" and have a line in the config file that specifies that "ij" means "www.insanejournal.com".)
Until I read your comment, the idea of a hosted solution didn't even occur to me -- this was all a "download it to your computer and install it there" plan -- but now that you've put the idea in my head I'll spend a little time thinking about whether a hosted version would make sense, and how I'd want that to work if so.
Er ... did I actually wind up answering the questions you meant to ask in there anywhere?