Global TV in Canada failed to air programs as per their schedule. Following a posting I made to their forums I discovered that they frequently shuffle things around and then never bother to alter their listings.

http://community.canada.com/webx?12@@.eeacf85/4

So the listing showed Friday Night Lights did indeed take House's 8pm slot. I could accomodate that - I just canceled my evening arrangements. But then Global in their infinite wisdom (sic) put Standoff where House was advertised to be.

Stupid stupid. They didn't even advertise Standoff! Standoff is good! Yet how many people missed it because it wasn't advertised?

And Friday Night Lights? Try selecting it from the drop down for Global Shows A-Z. Currently (7:52am, Weds 4th Oct) this goes to http://community.canada.com/globaltv/globalshows/fridaynightlights/index.html which results in a 404 not found.

Global: your website sucks. And as you syndicate your listings, everyone that carries your listings is also affected by your out-of-dateness. Do bare in mind that any site (e.g. yahoo.com) paying for your listings has reasons to sue if you can't keep to your word as to what's on. You are misleading us all.

And your viewers, like these above, can go elsewhere for their entertainment. Like bittorrent, for example, where they can skip your adverts and timeshift as they please.

Finally, Global, the field of competition will open up. Your competition will no longer be just the Canadian providers. As internet TV streaming comes into play we, the public, will be able to get programming from providers around the world. Like the BBC, or Fox TV.

Global takes value from being an intermediary. It is in your interests you remain a value-added one.

Lastly I wonder... what's Google Video and YouTube.com offering in this space? Does Global have a coherent actionable strategy to ensure no loss of viewers to the competition?

Technorati tags about TWiki show how much people are talking about it

Mike Saunders explains why Windows machines often lose time and what you can do about it using a registry key setting.

http://www.method.cx/~method/notes/XP-NTP-fix.html

Also, it makes me wonder: is this happening because of a low CMOS battery? I think there is an internal one.

As far as I can see, for all intents and purposes Acrowiki - a TWiki-compatible wiki for the Palm - is dead. Acrocat (the makers of PDA Abs) have simply abandoned it. Someone should buy it and put both Acrocat and their customers out of misery.

http://www.acrocat.com/bbs/forum_posts.asp?TID=516

Topic: Timeline for release? Posted: 19 February 2006 at 2:34pm

Will there be a new version out reasonably soon? ...

---

Posted: 14 March 2006 at 10:24am Is acrowiki a very secondary priority to pdaabs?

Please acrocat, tell us whether you intend to do anything more with this product.

And, if you don't, please sell it to someone who might.

Thanks, M.

---

Posted: 14 March 2006 at 6:37pm

Thanks for your interest! Unfortunately, we're not free disclose future product plans, but we do appreciate that folks are looking forward to new versions of AcroWiki and we do have new features planned, based on the Wish List and other topics.

Michele (Acrocat)

---

Posted: 19 April 2006 at 4:50pm Originally posted by Acrocat

Thanks for your interest! Unfortunately, we're not free disclose future product plans, but we do appreciate that folks are looking forward to new versions of AcroWiki and we do have new features planned, based on the Wish List and other topics.

By not disclosing such plans, you are treating your community of users like a foreign entity. You should embrace your community of users, since they are providing much constructive feedback in the face of an apparent lack of product release, and therefore are obviously quite enthusiastic about AcroWiki.

I'm sure that if you disclosed at least some of your plans, and were more active in following up feature requests (where's the feature request poll you promised in June 2005 to post?), you'd get more enthusiasm from your community of users. I'm keen to join that community, since I like AcroWiki, but if it appears to be unsupported then I will be reluctant to spend my hard-earnt money on it.

I was asked by a colleague the other day about purchasing a new PDA and/or smartphone, and should he go Windows or Palm, and can he get some sort of interlinking document editing system. I remembered AcroWiki and decided to revisit it to see if it would be suitable (for him and for me). I have found some shortcomings in the software, but nothing too serious. My biggest concern is lack of new releases, as this implies lack of support.

I hope that my feelings are wrong (as your recent return to the forums may indicate), and that a new release (even minor) is just around the corner, as I'm keen to purchase and use AcroWiki as soon as a couple of minor problems on my Treo 650 are solved (see my posts in http://www.acrocat.com/bbs/forum_posts.asp?TID=375 for some additional info).

---

From http://response39.blogsome.com/2005/07/04/wikis-and-palm-handhelds/ Wikis and Palm Handhelds Filed under: Palm GtD - Administrator @ 3:21 pm

Wikis and Palm Handhelds Another factor in my organizing style is that I see connections everywhere. I have notes about someone that lists the phone number or address, which connects in my mind to my address book/PIM/Palm. That’s why I was very excited to find wikis. My preferred wiki, only because it acts mostly the same on Palm or on desktop, is Note Studio. There are things it doesn’t do that I’d love to have it do. There are things it does that I’d rather it didn’t do. But all in all it does onething quite well - behaves the same on desktop and on Palm.

Before I bought my Palm T|E, I had an older Palm IIIC. It was fine, but I had to turn it back in when I switched assignments at work. The new office didn’t allow any Palms of any kind in the office area. When I switched, I lost my then favorite app - MegaWiki. That app was a neat gadget! I could link things all over my Palm. I could link to or from appointments (or create one if none existed), addresses, memos and todos. BUT… (there’s that big but again) it only worked on the Palm, there was no desktop equivalent. I didn’t realize how important that was until I used Note Studio. I tried several other MegaWiki-like apps - Acrowiki, PSLink, Mobile Note (the freeware ver 0.6), etc. - but none of them really fit the bill. Then I tried Note Studio and found out that the plus - desktop behaved the same as the Palm app - far outweighed the shortcomings.

Notestudio: http://www.dogmelon.com.au/NoteStudio.shtml

---

And given the fact that you cannot be bothered, after two weeks, to respond, I can only conclude that you are misserving yourselves and your customers. The fact that you have no messages for 6 months in your beta forum is further testement.

Acrocat has a good foothold in the PDA fitness market. With this it seems it does not need, care or have the ability to serve the wiki market.

So it should not bother. My advice - for what its worth - is that AcroWiki, has more value in the marketplace than it has in your firm. I suggest, Acrocat, that you divest by selling it to another vendor before lack of action further damages the Acrocat name.

MartinCleaver replies on " Some ideas to improve BlogPlugin ":

Default naming of topics is a common pattern: Socialtext, Note Studio and Confluence all handle it by defaulting to the time of posting. Not only is this unique it is somewhat meaningful.

However, using the time also raises the spectre of clashes and TZ ambiguity: the user would need to coerce the times into a single TZ. And where there are multiple TZs for multiple users no one is going to be particularly happy.

Where there is a posting headline then using this is potentially more meaningful, if it can be made unique. Wordpress allows the user to define the URI structure, allowing compositions such as date + user + title

TWiki's "Add Page" javascript mechanism (not used by NatSkin) has "Coerce a Valid Page Name" was based on the TWikiRegistration form for creating a username from the user's First & Last name. That needs to be made redundant, however, with an implementation also running server-side, if users who don't have javascript are to be served.

Creating such a server-side implementation of this "Coerce a Valid Page Name" would also go a distance to serve BlogPlugin: the coercion could happen primarily on the client side with server side back up.

Replicating content between wikis

From a market perspective, providing a wiki on the desktop goes a step towards enabling the mobile professional to work with wiki content. Lotus Notes is probably most people's experience with replication: content changes are permitted either on the desktop or on servers. When the two connect they share the list of pending changes.

Already there are wikis that provide replication from the handheld to the desktop: I'm currently experimenting with Dog Melon's Note Studio, which has a Palm - Desktop component. I don't know how well it handles conflicts, though this is less of a problem between handheld and desktop (two devices used by the same person) as it would be between a corporate wiki and potentially hundreds of users. Dog Melon also have a Pocket PC - Desktop edition. These cost $50, a bit unnecessary considering the open source options, especially considering that some stuff on my Treo I'd want to sync up to a server.

In July last year, during a quiet period at work, I built out a working prototype of replication between two instances of TWiki using Unison, a file-based replication tool. At the time I was excited about Acrowiki, by Acrocat software (formally called HWiki), a TWiki-markup compatible wiki that works on my Treo 650. Acrocat have gone shy about revealing anything about future versions and I drew conclusion (that they have yet to refute) that they've practically abandoned it. I can't even use the existing version as I'd need it to use files from the SD card in order for my unison solution to work with it.

Exchanging the content between unlike servers involves not just file replication but data transformation too. This problem is well understood by the Messaging Middleware people (I used to work with products such as TIBCO and IBM MQ) and would likely best be served in an XSL transformation mapping gateway. It'd also require an XML represention of each wiki's text. To my knowledge none of them have XML representations butall will export to XHTML as they have to get their content accepted by the browsers. Bayle Shanks did some pioneering work with the wiki-gateway, but I don't know whether that's progressed at all since.

Quite separately I read that Socialtext has built online access in miki a mobile-enabled version of socialtext. That's not replication, however, I imagine that its an appropriate set of skins formatted and laid out for the mobile device.

I'd like TWiki to become installable and useable by end-users, not just techies. On their laptops, PC and Mac.

There's something really attractive about having a wiki run on your desktop.

I'd like TWiki to become installable and useable by end-users, not just techies. On their laptops, PC and Mac.

There's something really attractive about having a wiki run on your desktop. Wikis provide a conversational context for content way more powerful that the single-category of files and folders view allowed by Windows Explorer. Windows explorer does allow a user to store a HTML file next to folders, but gives no way to generate this. Without lowering the effort required few people bother. Providing the wiki-context would allow for tagging and mapping and (collective) sensemaking / trails that wikis are now embodying, all on the local filesystem.

I first remember running TWiki on Windows back in 2002 when I helped roll out an installation for Arthur Andersen. Yet 4 years later this option is not generally accessible to the public as there is not a sensible windows build. Oh, techies can work it out, after say a couple of hours of effort following the IndigoPerl build instructions, or download the 200mb VMWare build, but long or technical installation instructions and enormous downloads are a real barrier preventing end-users trying out TWiki for the first time.

By opening TWiki to use by end users, would open the door to amplify usage to all the non-technical users, and in the process draw more technical users back into the fold.

To make such a point and click install possible what TWiki needs is a Windows Native build that double-click installs from a .exe and that does not involve an emulation layer such as CygWin or VMWare.

This integration build effort started - see TWiki:Plugins.TWikiInstallerWindowsContrib: we have the components and the approach but not the build. Like too many of TWiki's projects it has failed due to poor coordination.

Many blogs allow the user to email in to post content.

Blogs such as blogger and wordpress allow email-in. They typically set up a secret email address, content emailed to which arrives in the blog. It would be nice if TWiki:Plugins.BlogPlugin could do the same.

This is a varient on the rest method of posting content.

Here's a smattering from the blogs of people that went to MESH Toronto 2006

http://www.gagglescape.com/

MartinCleaver replies on " Back-blogging wiki entries ":

So its not a case of TWiki:Codev.ImplementBeforeTheCompetition...

MichaelDaum replies on " Back-blogging wiki entries ":

How about to using PinkBack for exactly that. You could write topics from within your own blog or wiki, refer to a TWiki.org topic and get that inserted there on a dedicated corner of the page.

But that means TWiki.org topics must become pingable which is not very likely to happen any soon.

If we had a PingBackPlugin we could have networks of wikis.

MichaelDaum replies on " Some ideas to improve BlogPlugin ":

Having cooler urls for BlogEntries would be nice. But I want them to be created automatically. Other TWikiApplications add the ability to decide yourself on the name of the new topic to be created. That's not what I want to do. As your above example supposes the topic name can in principle be derived from the headline or topic description of the BlogEntry, BlogComment or BlogPage. The pattern how to derive and which information to take is quite application-specific. This needs more rethinking.

The standard Xx10 mechanism is the obvious thing to do for now. The BugsContrib does that too.

MichaelDaum replies on " Some ideas to improve BlogPlugin ":

Martin, we had that for ages. We discussed that via email. You keep asking me on IRC and you always come up with the same arguments again, presenting them without my weak excuses. Have you forgotten you what I emaild you in response? Last thing I remember that we did start to compare different desktop applications and what their terminology is. So, sigh here is my response again on NatSkinDev. Please feel free to extend the survey there with counter examples.

Treo just crashed again, running NoteStudio. Is it stable?

I'll record incidents here.

Every wiki has its own markup, but how well designed are they? One way to tell is to see how hard it is to use a different markup

TWiki, Confluence, Note Studio - I use all of these and they all have proprietary mark-up (e.g. text-only representations of how to do *bold*)

Its not a problem until I want to push the content beyond the scope of the application. I enter stuff on my Palm Treo 650 copy of Note Studio - I want it to appear on the company wiki. Even if I can get the content over there it would need reformatting.

Bayle Shanks (who I met at WikiSym2005) wrote a wiki gateway to handle the API part of submitting content to a generic interface. I wrote the TWiki:Codev.SyncContrib (although it remains fairly uobscured in TWiki's SVN) but that only handles TWiki-TWiki syncronisation. And AcroWiki appears to have been completely abandoned by Acrocat software presumably because they have made a name for themselves on pdaabs and acrowiki is not core to what they do.

This leaves me with an integration gap. And while I as a techie could solve it I neither have the time nor inclination to do so. Further, integration is a key step to simplicity: most users see such problems as completely insumountable.

Blog Plugin is better than anything else for TWiki but still has a way to go.

I like BlogPlugin, despite the short-comings I mentioned yesterday.

Here's a few things that keep irritating me:

• The "Quit" button. Apparently I'm supposed to "Quit" to save and Exit. Sorry, Quit is a type of "discard" to me. BlogPlugin invokes NatSkin on my install: the problem belongs there really. http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item1093 has my bug there, Micha moved it to TWiki:Plugins.BlogPluginDev, presumably because he finds that more usable than http://develop.twiki.org/~develop/cgi-bin/view/Bugs/BlogPlugin. (I disagree, not least because there is no way on the Dev topic to hide completed stuff).
  • Marcus Leonard commented "Quit" really does sound like "bail out", not "save".
• Blog Entry naming - every other blog makes the entry URLs intention revealing. And such URL transparency is a key feature of wikis. I'd want this entry to be called something like "BlogPluginIsBetterThanAnythingElseForTWiki..." but its ended up being called something like BlogEntry9
• I use ALT-S to save and Exit. NatSkin breaks this as that means "checkpoint in NatSkin"

twiki, jotspot, phpwiki, mediawiki, xwiki compared. Mediawiki has pulled way out front since early 2005.

People (myself included) have always thought of JotSpot, Confluence and Socialtext as being the commercial wikis that generate the most buzz.

These pail into insignificance compared with the coverage of the twiki & mediawiki.

Mediawiki's use on wikipedia makes it the defacto php wiki. Shame for PhpWiki really: http://google.com/trends?q=mediawiki%2C+phpwiki&ctab=1&geo=all&date=all

I took socialtext out of the comparison as Google does not have stats on it since Q3 2005. Their stats look wrong anyway so its best to simply not talk about them. http://google.com/trends?q=socialtext%2C+jotspot&ctab=1&geo=all&date=all

Confluence as a term is too generic to reliably pull stats from, as it is also an English word. "Atlassian Confluence" returns fewer hits than it deserves.

Thousands of wiki entries - could all be blogged.

I've contributed to TWiki.org for about 5 years. This must amount to thousands of entries. As a blog is a personal journal it would be useful to automatically enter these into my blog.

To do the retrospective entries I would need to process TWiki.org. While I was there I might as well extract everyone else's entries. These would then need to be inserted into my blog. That would most usefully be done as an xml-rpc / rest call.

To do the forward entries the most obvious option would be to listen to RSS: that would be a fairly generic solution.

rest for TWiki:Codev.BlogUp is not yet complete. I have a theory that it might actually already work, it's just that no one's worked out the call syntax.

As I am well over worked there is no way that I'd have the time to back-blog the entries, nor write the forward-blog rss listener but its worthy for any TWiki Constributor just for the Blog reputation effect.

I seem to have had a very techie night! Quite unexpected. Anyhow, I was telling Jason how to build and install scheduler contrib and it was quite apparent that its not obvious where TWiki keeps its MANIFEST and how to get build to work with remote TWIKI_LIBS.

So here you are...

(11:51:45 PM) MartinCleaver: [twiki4prod@host SchedulerContrib]$ perl build.pl release
(11:51:45 PM) MartinCleaver: Building a release
(11:51:45 PM) MartinCleaver: Version 9870 of SchedulerContrib
(11:51:45 PM) MartinCleaver: Package name will be SchedulerContrib
(11:51:45 PM) MartinCleaver: Topic name will be SchedulerContrib
(11:51:45 PM) MartinCleaver: Auto-adding install script to manifest
(11:51:45 PM) MartinCleaver: Release ZIP is /home/twiki4prod/10244/twikiplugins/SchedulerContrib/SchedulerContrib.zip
(11:51:45 PM) MartinCleaver: Release TGZ is /home/twiki4prod/10244/twikiplugins/SchedulerContrib/SchedulerContrib.tgz
(11:51:45 PM) MartinCleaver: Release TOPIC is /home/twiki4prod/10244/twikiplugins/SchedulerContrib/SchedulerContrib.txt
(11:51:45 PM) MartinCleaver: MD5 checksums are in /home/twiki4prod/10244/twikiplugins/SchedulerContrib/SchedulerContrib.md5


---


QBFreak: in twikiplugins/SchedulerContrib ?
MartinCleaver: y
QBFreak: where is build.pl, I don't see it at first glance
MartinCleaver: in twikiplugins/SchedulerContrib/lib/TWiki/Contrib/SchedulerContrib
MartinCleaver: stupid place I know
QBFreak: ah ok
QBFreak: I remember the funny nesting, thats MANIFEST related right?
MartinCleaver: yup
QBFreak: not linking @INC
QBFreak: liking
MartinCleaver: oh, I have a little script:
MartinCleaver:  cat setenv.sh.dotme
MartinCleaver: export TWIKI_LIBS=~/public_html/twiki/lib
MartinCleaver: so just . ./setenv.sh.dotme
QBFreak: set that to the checkout's lib?
MartinCleaver: a working twiki, y.

MichaelDaum replies on " Martin starts Blogging... with BlogPlugin ":

Hope to see your site ``personalized''.