Loading ...
Sorry, an error occurred while loading the content.

Re: [extremeperl] FUD Starts Early

Expand Messages
  • Rob Nagler
    ... Since there s been an overwhelming demand for a blog, and since this list has been getting more noise than signal lately (those buggers registered a bunch
    Message 1 of 10 , Mar 18, 2006
    • 0 Attachment
      Mark A. Hershberger writes:
      > What a coincidence! I write on my weblog by typing text in emacs and
      > typing C-c C-c! (weblogger.el is my secret weapon.)

      :-)

      Since there's been an overwhelming demand for a blog, and since this
      list has been getting more noise than signal lately (those buggers
      registered a bunch of addresses a while ago, and are using them. I'm
      tempted to kill all .in and .cn addresses in attempt to stop the
      blight, but I digress...), I'll write a bit more about a recent bOP
      change. FYI, I am writing this as much for bivions as for the OSS
      community, just like I write code for my customers as much as for the
      programming community...

      I added a Wiki (per a customer request, of course :-) to bOP this
      week. I also added a feature that allows our customer to use the Wiki
      to write help text. WikiView.pm outputs XHTML, and the customer can
      control the L&F by adding a base.css to the wiki directory. And yes,
      as with everything in bOP, each Realm can have its own Wiki.

      In the process of creating the Wiki, I was trying to figure out why
      blogs, wikis, etc. are interesting. They are all CMS technologies and
      they compete with each other. In bOP, they work together. To create
      a blog, all you'd have to do is render the RealmFiles in a Table
      ordered by date with WikiView. A blog is a chronological wiki. A
      wiki is a blog with clear and uniform naming.

      The way I see it, Wikis, blogs, html, etc. are an attempt at
      decoupling the content from the presentation. It's a problem the
      software industry has been repeatedly solving since at least the
      1960s. It's really not that complex a problem -- hence the
      re-inventions. It seems to me that programmers like solving simple
      problems with complex solutions, because it's too hard to actually
      write and re-use good abstractions. It's one of the reasons why CSS
      is so messed up even though there were innumerable better solutions to
      the problem of decoupling formatting from content prior to the
      invention of CSS, but I digress again...

      Why did I write my own wiki? Blogs and wikis get one thing wrong that
      bOP gets right: groupware. They focus on the content creation and
      naming, which is a trival problem, and they often do a bad job at it
      imiho. weblogger.el seems like an odd mix of bad ideas, too. Why
      does it use XML-RPC, when WebDAV has been around longer and is
      supported by more web servers?

      The two problems CMSes solve that general groupware systems don't
      solve: naming and formatting. Groupware sometimes handles formatting,
      but the point of groupware is to solve the
      security-for-shared-resources problem. In other words, good groupware
      gives the appropriate access to files and other communications to
      people in a group. The formatting problem is something that you throw
      on top of groupware, because people do need to format their content
      every now and then. CMSes also handle versioning, but that's not the
      topic I'd like to talk about today, and it really is distinct from
      naming and formatting.

      Assuming you've solved the file access problem, you'll use those
      abstractions for the Wiki so all I have to think about is naming and
      formatting. Naming in Wikis is just fine. CamelCase works, and I
      just used that. You also want to match email addresses, domain names,
      and local file references, and so one. In our wiki, you refer to an
      image in the wiki folder by naming it, e.g mypicture.jpg. The wiki
      formatter turns it into an <img> link just as it turns emails into
      mailto's. (This is a private wiki so we don't care about hiding
      addresses, and if we needed to, we could make the mailto: be a local
      form email so the address doesn't get public.)

      The general formatting problem is interesting. Just like this email,
      I use blank lines for paragraph delimiters. I also allowed _italics_
      and *bold*, but that's it. I didn't want to invent my own formatting
      language, and I wanted to keep the essence of a wiki which is: it's
      the content stupid. If you want to format, use HTML, Illustrator, or
      TeX.

      I tried to avoid the introduction of syntax for names of things,
      because an interpreter can easily discern between the many types of
      external objects we need to name and ordinary natural language.

      I do know my customer wants bulleted lists, and a few other things
      like strikeout and underline. I also know that with a collaborative
      mechanism, there would be a price to pay if the syntax was not easily
      usable by experts in HTML, and at the same time, understood by
      people who don't like matching up angle brackets and tags so here's
      what I came up with:

      @ul
      @li The syntax uses html tags so I didn't invent the names.
      @li Similar tags close each other like good ole HTML 1.0.
      @li Tags must begin at the start of a line so @perlvar is not treated specially.
      @li
      Only formatting tags were included, not @form, and @script,
      This wiki is about content, which can be inserted in places,
      and can link to the main HelpWikiHelp.
      @ul

      The wiki interpretation code is in a single 280 line module:

      http://www.bivio.biz/f/bOP/lib/Bivio/Type/WikiText.pm

      And since this an XP lists, here's the unit test:

      http://www.bivio.biz/f/bOP/tests/Bivio/Type/t/WikiText.bunit

      I hope those of you have read this far have found this useful. It's
      the type of stuff that doesn't appear in code, and shouldn't. It's
      not the type of stuff I can spend my time on, because I'm a much
      better coder, and I strongly believe programmers learn the most by
      trying to figure out abstractions rather than reading about them.
      However, I thought I'd try this for a change and see what feedback I
      get. :-)

      Rob
    • mah@everybody.org
      ... Why would people want to publish a weblog using Blogger s services? Whatever the reason that is why blogger.el was written to use XML-RPC. weblogger.el
      Message 2 of 10 , Mar 19, 2006
      • 0 Attachment
        Rob Nagler <nagler@...> writes:

        > weblogger.el seems like an odd mix of bad ideas, too. Why
        > does it use XML-RPC, when WebDAV has been around longer and is
        > supported by more web servers?

        Why would people want to publish a weblog using Blogger's services?
        Whatever the reason that is why blogger.el was written to use
        XML-RPC. weblogger.el built on blogger.el's work to support the
        MetaWeblog API that many weblog frameworks (e.g. LiveJournal,
        Wordpress) support.

        If you would rather write a bunch of static files to the server, then
        other Emacs-based solutions exist:

        - BlogMax (http://www.billstclair.com/blogmax/blogmax.el)

        - Planner.el (http://www.plannerlove.com/) Sacha Chua maintains
        planner.el and uses it to publish her weblo
        to integrate her del.icio.us tags with her journal entries that she
        then publishes on her weblog.

        And there are others....

        Mark.

        --
        http://hexmode.com/
        GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5

        In the end, the only events in life worth telling are those in which
        the imperishable world erupted into this transitory world. --Carl Jung


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.