I've taken the liberty of writing another patch for blogpost which adds
a small amount of additional functionality; it can now read the blogpost
categories from the asciidoc file, specified as attributes in the file.
You specify the option (I picked -a for attributes!) on the command
line, and post, create or update and it all works.
The reason that this would be really nice is that I can now stick all my
blog posts in a directory and then use a very simple makefile (comparing
the asciidoc to the .blogpost file) to autopost any changed files.
This makes life easier when on the road; you don't have to remember what
you have posted and what not.
I'm afraid that I couldn't get your current version hg version working;
this is due to a problem in asciidocapi.py, which I couldn't figure out
(cause I am about off on holiday!). So this patch is against 0.9.1 with
the last patch I sent applied. Sorry for making your life harder; I
promise to learn mercurial before sending more patches!
Okay, last time, I promise. I've patched the last patch to allow
blogpost to read the status (published, unpublished) from the asciidoc
file also. This turns out to be the last piece that I needed for me
"post everything with make" plan.
The diff includes the last one; but is after the changes for "post".
I really will learn mercurial, when I get back from holiday!
In a way, you can could ask the same thing about the title, which is
read from the asciidoc file; I would guess that this is also in the
Finally, I think that there is a big convienience issue. I can type the
categories in at the time that I am writing, not posting (which may be
very different) and, with the status and categories patch) I can judge by
looking at the asciidoc source how the post will be; I don't need the blog
online to know.
For me, it's a great convienience; I was going to write a tool over the
top of blogpost which uses it as a library to achieve the same end (which
is trivial to do). But having it in blogpost seems more sensible.
Your call, obviously. Either way works for me.
Sorry for delay! Been away.
I've reused a piece of asciidoc syntax (just added additional semantics)
to encode the status and categories of the blogpost; as far as I know,
there's no particular reason this syntax should change either.
It also has the virtue that if you want you can refer to the categories
in text (as they are asciidoc attributes). A small virtue, I guess, as I
can see no reason why you would want to do this:-)
>> Finally, I think that there is a big convienience issue. I can type the
>> categories in at the time that I am writing, not posting (which may be
>> very different) and, with the status and categories patch) I can judge by
>> looking at the asciidoc source how the post will be; I don't need the blog
>> online to know.
>> For me, it's a great convienience; I was going to write a tool over the
>> top of blogpost which uses it as a library to achieve the same end (which
>> is trivial to do). But having it in blogpost seems more sensible.
>> Your call, obviously. Either way works for me.
> I can see that it would be convenient, but it pushes a blogpost related
> coupling into Asciidoc.
In a sense, yes. It's still valid asciidoc syntax; if you asciidoc
(rather than blogpost) an article using this feature, then the just
Also, my patch required use of a command-line option; so this coupling
is not required or even the default behaviour.
> I think the place for blogpost specific information is the .blogpost
> file not the AsciiDoc source. Here are some random thoughts:
> - If the .blogpost files were YAML instead of the pickled format they
> could be easily edited alongside the AsciiDoc source files.
That might make sense, but the .blogpost file does require procedural
generated information (ID, dates, what's been uploaded and the like).
So, I don't think you are going to get away from having a picked
I did at one point think about providing a metadata file with the
information in it. So, you'd have had post.adoc, post.meta, and
post.blogpost (generated). But, ultimately, I can't see that this a big
advantage, given that the asciidoc syntax provides a naturalistic
extension point. And I have to open two files to get a complete picture
of the blogpost.
> - Alternatively a --cache-only (--local ?) option that would update the
> local .blogpost file but would suppress the upload.
> - Or more simply, if the upload fails then continue and update the
> .blogpost file (but not the created_at or updated_at fields) -- but this
> doesn't give you the ability to hold back the upload.
Both of these would work. Again, from my perspective, it's easier to
have the info with the source; for me, the categories are part of the
blogpost. I want to read them both at the same time.
As it happens for my specific use case, this would also not work,
because the date of the .blogpost file would not longer be an accurate
reflection of the last blog update. So, make wouldn't work. Perhaps this
doesn't make any odds because blogpost works out for itself whether it
needs to repost; it probably does a better job of the dependency
analysis than make.
Apologies for not getting back sooner. I'm rereading the posts and am warming to
your ideas :-) This is why I like email discussions, they give me days and days
to mull things over (some would say procrastinate) -- I'm no good at thinking on
Anyway, here are some more thoughts:
Why not have the post command simply check for a :categories: attribute entry in
the AsciiDoc source file and update the categories automatically? This would
eliminate the need for a separate --read-categories command.
Take it to the logical extreme and allow all .blogpost meta-data attributes (id,
url, status, categories, type, created) to optionally reside in the AsciiDoc source.
A single e.g. -m, --meta-data option would signal blogpost to create/update/read
attributes at the start of the AsciiDoc source file (warning the user if there's
an existing .blogpost meta-data file).
This option would obviate the need for separate .blogpost cache files. I must
admit that having separate files is always irritating and error prone, maybe the
default behavior should be to store meta-data in the AsciiDoc source.
One of the great things with free software that you are not paid to do,
is that you get the right to do things whenever you want (or not at
all). For me, this tends to mean that I get the chance to think about
new features rather than rush them out; my experience is that the
software is better as a result. Looks like you feel the same way!
> Anyway, here are some more thoughts:
> Why not have the post command simply check for a :categories: attribute entry in
> the AsciiDoc source file and update the categories automatically? This would
> eliminate the need for a separate --read-categories command.
This is a good idea. I think that the only disadvantage is that
--read-categories, as well as suggesting to blogpost that it should look
for the attribute also forces an error if it's not there. I have
--read-categories in my make file; if I forget, the post is aborted. I
like this behaviour.
> Take it to the logical extreme and allow all .blogpost meta-data attributes (id,
> url, status, categories, type, created) to optionally reside in the AsciiDoc source.
This would make sense, yes, with the previous caveat of error
conditions. I don't want to give id and url; am happy for wordpress to
just assign those (in most cases anyway); so an error condition in this
case would not be idea for me.
> A single e.g. -m, --meta-data option would signal blogpost to create/update/read
> attributes at the start of the AsciiDoc source file (warning the user if there's
> an existing .blogpost meta-data file).
> This option would obviate the need for separate .blogpost cache files. I must
> admit that having separate files is always irritating and error prone, maybe the
> default behavior should be to store meta-data in the AsciiDoc source.
For me, the .blogpost files serve a useful purpose; they time stamp the
latest version, which make uses to work out what needs to be posted. Of
course, blogpost knows this also from the cache file, but make is
But adding a pile of command line switches for all the metadata would be
a pain in the ass. Perhaps, instead, you could do something like
blogpost --metadata=status,type,categories post thing.adoc
Blogpost would then look for only those items after --metadata and
signal errors if they were not there.
Tong <sunto...@gmail.com> writes:
>> This is a good idea. I think that the only disadvantage is that
>> --read-categories, as well as suggesting to blogpost that it should look
>> for the attribute also forces an error if it's not there. I have
>> --read-categories in my make file; if I forget, the post is aborted. I
>> like this behaviour.
> - when blogging, people would normally focus on a certain area at a
> time, so several pre-set category files might suits over 80% needs.
> Thus eliminate the need for typing repetitive categories attribute
> each time.
Not quite sure what you mean by this.
> only my 2c though.
>> But adding a pile of command line switches for all the metadata would be
>> a pain in the ass. Perhaps, instead, you could do something like
>> blogpost --metadata=status,type,categories post thing.adoc
>> Blogpost would then look for only those items after --metadata and
>> signal errors if they were not there.
>> Sounds reasonable?
> yeah, very reasonable to me. I use make files as well, but not on
> blogpost yet. Would you share your make file for blogpost out please,
Sure, they are very simple; I'm afraid it's rather specific to my
I have four files.
"Makefile" which is just an include.
It depends; currently I keep my asciidoc files in a "per month"
directory, but I was going to move per year; this makes about 70 or 80
files per year. If I need to check all of these files with an XML-RPC
call, it's going to be slow. I agree that the timestamps can get out of
Of course, this behaviour is easy to replicate -- I just touch an empty
file when blogpost exits correctly.
If blogpost is optional, though, where are you going to store the "media
I've uploaded" data? Is the plan to put ALL of this in to the asciidoc
file? This is a nice idea in some ways, but it is going to mean updating
a file that you might also be editing.
I guess I am confused about the "storing metadata"; some metadata is
user derived, some wordpress.
> Store metadata in AsciiDoc source file instead of .blogpost
> cache file.
> Update blog using metadata from the AsciiDoc source file. ATTRIBUTES
> is a comma-separated list of metadata attribute names. Valid names
> are categories, status, type. An error occurs if any of the
> ATTRIBUTES are missing from the AsciiDoc source file.
> This scheme retains the current behavior as the default behavior.
> blogpost -m --read-categories=categories,status post mydoc.txt
> Reads categories and status from mydoc.txt and updates mydoc.txt.
> blogpost --read-categories=categories,status post mydoc.txt
> Reads categories and status from mydoc.txt and updates mydoc.blogpost.
--read-attributes, I think. Yes, this is fine, with error conditions if
> blogpost -m post mydoc.txt
> Reads metadata attributes from mydoc.txt, assigns default values to missing
> attributes and updates mydoc.txt.
Makes sense to me. One noisy, one quiet. Or one with defaults, one
without, depending on how you look at it.