Small thing, but wouldn't the following AgentQuery be better for /Atom Feed ?

Code:

inside("/RSS Feed") 

Or maybe better yet have a Feeds agent in UTILS that both feed exports source from.

Another thing I was thinking of that might be cool is a form of internal version checking. It could be very basic, but the document could output a small page with a version number, and then another note could fetch this generated page from the web site. A very low priority agent would check the contents of both, and if they do not match, would move itself to the top level, set itself red, and declare that the local version is out of date.

Good point, though I guess I was thinking more along the lines of demonstrating abstracting agent code when two or more agents are using identical methods to show how keeping things central reduces maintenance hassles in the long run, rather than trimming agent times which as you point out are already good. Perhaps abstracting is a bit much for an introductory document, though, you could be right there.

Here is a solution for the version checker which looks like it can be accomplished with a single note and attribute:

Attribute: MyVersion

Note (/UTILS/Version Checker):

Text: `5.0.0`
MyVersion: `5.0.0`
DisplayExpression: `$Name + " (" + $Text + ")"`
AutoFetch: `true`
URL: Set to wherever this note will generate.
Rule: `if ($MyVersion != $Text) { $Color = "red"; $Container="/"; $Name="New version available"; } else { $Color=; $Container="/UTILS"; $Name="Version Checker"; };`

The template for this item would export MyVersion instead of Text, so the website version would fetch with whatever is the current version of the document. However the user’s downloaded copy would have Text set to whatever the website is reporting. The reset stuff in the Rule is probably not necessary, I just had it in there for testing.

One problem with this is that older versions of the web site (say the user was using a pre-release) would report as well. Perhaps a numeric and then math instead of string matching would be an alternate solution.

I have tested this by setting the URL to a text file on my web server[1] that simply says ‘5.0.1’ and then setting MyVersion to ‘5.0.0’. When the document loads, it fetches the URL, notes the mismatch, and moves the note to the top level. The only issue is that it gets moved to the very bottom of the outline, but since OutlineOrder is read-only, I’m not sure how to get around that. Perhaps have the Rule modify the attributes of "/A Tinderbox Reference File" ?

This might be a good recipe for other Tinderbox documents as well that need to keep themselves up to date with a central source, or are distribution based periodicals, et cetera.

Footnotes:

• [1] If you want to test this, the url is here.

Amber's idea is neat and took me back into some features I rarely use - like AutoFetch. I modified things slightly.

New User Attribute: MyVersion (String data type)

New note at root level "Version Checker"

New note's settings:
$Text: 5.0.1
$MyVersion: 5.0.1
$DisplayExpression: $Name + " (" + $Text + ")"
$AutoFetch: true
$URL: http://www.acrobatfaq.com/atbref5/vc
$Rule: $MyVersion= $MyVersion(Change Log);if ($MyVersion != $Text) { $Color = "red"; $Container="/"; $Name="New version available"; } else { $Color=; $Name="Version Checker"; };
$KeyAttributes: MyVersion;URL;AutoFetch;ReadOnly

You don't need to set up the above - it's all done for you in the v5.0.1 aTbRef TBX I just uploaded.

Changes from Amber's demo:

• I moved the checker out of /UTILS as that container contents are basically non-exporting hidden 'internals' for doc. So, the checker note is now at root level at the bottom of the document. Being at root level the exported checker file is at the website root level too.
• As part of updating for a new TB release, I add a new agent inside 'Change Log' and its MyVersion value will be set for that release, e.g. currently '5.0.1' The parent Change Log container lists the releases in reverse order so the latest is the first child; it sets its $MyVersion to that of the first child. In turn the Version Checker sets its reference MyVersion from the Change Log.  That way the checker is automatically re-set in the TBX when I add into for a new version - less for me to forget.

A limitation of this is it doesn't tell users of local versions if I update the TBX outside a formal release; I do the latter pretty often.

Anyway, I hope this helps those using my TBX locally - either in TBX or output to local HTML pages. Once you have the v5.0.1+ aTbRef TBX you'll have a zero configuration update checker. If you want to cut down network activity you can always open the Version Checker note and temporarily toggle the note's $AutoFetch to false (un-ticked) though you're then responsible for remembering to turn it back on.

For 'local' users there's one other tip. If you can't download the images but have web access, the $URL for notes using grabs currently  holds an absolute URL for the image (NOTE: I'm not promising to keep doing this as I don't use it and it's a pain to keep updated). To make your local pages use my online images, open the templates using images, and find the ^do(ImgTag... references. You then replace the macro's first parameter:
  ^root^images/^getFor(this,WebImage)^
...becomes:
  ^get(URL)^

Just fixed a couple of typos and more importantly the TBX zip no longer includes path info so unzips in site rather than recreating it's path on my system. If you downloaded the TBX since my previous post, pick up the latest. The build checker should alert you anyway. For reasons I don't quite understand, the checker AutoFetch can take a minute or two to sync properly - even if I press the 'Fetch Now' button on the Network dialog.

Very happy to change the message. Care to suggest a better title? How about "aTbRef for v[version] has been updated. Download from $MyURL". I've added $MyURL as as a key attribute to each checker note. If the note turns red, open the note and click the globe nest to $MyURL. Simple enough?

Ah fixed the comparison.  The build checker was emitting a space before the number - tracked to TB's ANNOYING habit of inserting white space, on an arbitrary basis before pasted content.  Fixed that so now the vbc contents should be just a number. I coerce it to a number ($MyNumber=$Text) then text if $MyBuild is less than $MyNumber.

Update with above changes uploaded. See what you think.

[Later...] Here's the new-style checker:

$MyBuild < $MyNumber? Doh! I was forgetting that my local version should always be in date. Fixed: edition 21 uploaded.

I think it's worth using Cmd+3 to open the Network dialog and push the "Fetch now" to get the update process working. Indeed I find I need to push the button 3 or 4 times before TB actually responds.

~~~~
Beyond my skills but it did occur to me, from making the 'Zipper' process that the last note to export could actually go on to call an FTP upload or network synch. That said I tend to do updates by hand in Transmit as most automation tools are too slow/dumb to do it right.  Synching local and remote sizes can take 20 minutes whereas a full upload is a fraction of that time - partly because the latter uploads up to 8 files at a time and the synch does one (is there a workaround?). Also, an update process needs to know that the key change markers (basically the root folder contents) should be uploaded last.

Still I note this latter idea in case it might be of use to others doing this sort of output.

Thanks, some nice ideas now.  I think I'll stick to 'manual' FTP for now - if only to give more chance for me to avoid mistakes.  It's not like I upload the whole site every day.