I am working on my Atom feed exporter, with the hope of eventually making
it a plugin. Right now it works using the *rendertiddler *command under
node, and in fact is depending on a node library (crypto) being in place.
This is because the Atom spec <http://www.ietf.org/rfc/rfc4287.txt>
requires an "id" (a GUID) for each article (tiddler) in the feed:
4.2.6. The "atom:id" Element
The "atom:id" element conveys a permanent, universally unique
identifier for an entry or feed.
...
When an Atom Document is relocated, migrated, syndicated,
republished, exported, or imported, the content of its atom:id
element MUST NOT change. Put another way, an atom:id element
pertains to all instantiations of a particular Atom entry or feed;
revisions retain the same content in their atom:id elements. It is
suggested that the atom:id element be stored along with the
associated resource.
The content of an atom:id element MUST be created in a way that
assures uniqueness.
I decided to use an MD5 hash of each tiddler's title to generate a 128-bit
hash, which I then format into a GUID. It works quite well, and I think for
most foreseeable cases satisfies the spec. I did some research and then
decided to use node's crypto package, since it had an implementation of MD5
with an easy API. All is good.
However, when I *browse *to my TW (the original, not the generated static
output or feed) as opposed to running *commands *on it under node, it gives
an error at start-up in my module which ultimately I traced down to the
require("crypto") statement because node's crypto package is not available
when running in the browser (which makes sense). I could probably do some
work in my module to try and detect whether it's running in the browser or
under node and just export an empty *run *method when in the browser
environment, but that would invalidate one of Jeremy's wishes, which is
ultimately to be able to generate a feed under a browser-only TW.
So, I see a few possibilities, and want to ask which way is the TW way?
Jeremy, I'm especially looking from feedback from you on this. I have this
specific use-case, but am also interested in general to the TW approach to
external dependencies and libraries.
1. Figure out another way to reliably generate those GUIDs in a repeatable
manner (same tiddler always gets the same id). Definitely doable, but I
hate reinventing wheels.
Pros: Eliminates external dependencies.
Cons: Reinvents wheel.
2. Copy in the appropriate pieces of the node code or someone else's open
source implementation (with an OSS license that explicitly allows that -
node's seems to), presumably into TW's crypto module.
Pros: Wheel already invented, TW's crypto module probably needs some
expansion over time anyway.
Cons: Still maintaining another copy of code, "cut & paste" programming at
its worse, with all that implies, including maintenance in case of bugs
upstream, etc.
3. Build TW with the node crypto module included somehow - waving arms here
a bit.
Pros: Wheel already invented.
Cons: Requires node, but that's already a requirement, anyway?
4. ???Something else??? I note that the *utils *module has a *hashString
*function
exported, but it's only a simple 32-bit hash with high possibility of
collisions. It looks like TW2 had SHA1 hashing code, but (a) that appears
to be unused except for creating a "classic TW" edition, and (b) that's a
160-bit hash, not the 128-bits I would need. Other possibilities? Something
I'm missing (likely)?
Comments and discussion appreciated.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
