Blogging Roller

For the links I'm finding today.

• Via Sam Ruby: CSS border-radius property. No, it doesn't work on old legacy browsers like IE6.
• Via redemption in a blog: Longhorn has leaked out and the screenshots are starting to appear.
• Via The Server Side: <a href= "http://crazybob.org/roller/page/crazybob/20031024#strut_like_webwork_sort_of"> Bob Lee for having Struts Actions delegate to Struts Forms for presentation logic.

Good news via <a href= "http://www.werner.be/blog/page/werner/20031025#myeclipse_3_6_3_eclipse">Werner and just in time too. I was getting ready to back out of Eclipse 3.0 M4 because my MyEclipse order was just approved and I assumed that MyEclipse would not work with M4. Now I don't have to back out.

Apple has roughly 1% of personal computer marketshare, so why am I hearing so much about the new Mac OS release? Seems like everybody I know is excited about Panther and every weblog I <a href= "http://www.raibledesigns.com/page/rd/20031025#upgrade_to_panther_not_pretty"> read is Panther, Panther, Panther. But no Panther for me because I don't own a Mac. In fact, I've never owned anything manufactured by Apple, until now that is. I went out yesterday and treated myself to a 20GB iPod. What a beautiful and useful device. I'm a little worried that the iPod is like a gateway drug and I'll soon find myself jonesin' for a Powerbook and waiting in line for new Mac OS releases.

I finally got around to installing Roller at work. How did I justify this narcissistic activity? I'm responsible for our product's internal demo site and what better way to keep the sales force up on the latest code drops than a Roller-driven weblog. It took me about 30 minutes to install Roller, get it working with PostgreSQL (my group's open source database of choice), and hack together a nice corporate theme. One minor problem: the Roller main page is broken under PostreSQL, but I don't really need it so I disabled it for now. Maybe somebody else has alredy solved this problem. Anybody else try Roller 0.9.8 under PostgreSQL?

The Kids Are Alright is out on DVD.

Michael Thomas of the Triangle Internetworkers (INW) has an interesting idea. The Triangle Internetworkers is "a geographically defined, loosely knit group of technology workers who like to get together once a month and socialize." Between monthly gatherings the group hangs out on a busy, sometimes noisy, and comfortable mailing list. Michael sees value in the group's discussions and wants a way to share this value on the web by developing a community website that is driven by content posted to the INW mailing-list.

To make it easy for mailing-list subscribers to opt-in to the website and to ensure that the mailing-list's unique eco-system remains intact, Michael wants to develop a system based on simple markup-language that subscribers can use, or choose not use, within their email messages. The markup will indicate the message content and message meta-data like title, category, etc.  He's written up the requirements and the motivations behind this idea and some initial design ideas.

Michael's requirements and design do not mention weblogging even once, but this is obviously a weblog application.  By using a weblog the Internetworkers will have complete control over site layout and design, categorization, permissions, RSS feeds, Blogger API, comments, etc. Somebody has got to have done some mailing-list weblog integration work already, but I can't find anything except a plea for mailing-list weblog cross-polination from Tim O'Reilly. Finding nothing, I decided to come up with some suggestions on my own:

• One approach would be to write a program that can itself subscribe to the mailing list. This program will receive each email message, parse the markup, and use some logic to decide what to do with the mail message. This program will use the widely-supported and XML-RPC based Blogger API to post and publish messages to a weblog. Using the Blogger API, messages could be "posted" and then the owner of the weblog could choose whether or not to publish them via the weblog's administration pages. Or, alternatively, all messages could be "published" automatically without intervention of the weblog owner. You could write this thing in Java, Python, Perl, C# or just about anything. It would be helpful to have a XML parser, or better yet an XML-RPC client library (there are many implementations), or best of all a Blogger API client library. The advantage of this approach is that you don't have to modify the weblogging software, so you would have the option of hosting your blog on one of various inexpensive or free blogging sites like Blogger.com, Typepad.com, or one of the free Roller sites.
  
  
• Another approach might be to start with Moblogger. The open source Moblogger, developed by Russell Beattie, is a program that  "runs as a background process that monitors a POP3 email account for new email, then downloads it, detaches any files such as pictures, sound or video, uses the Blogger API to post the text in the email to your blog and uses FTP to post the files to your server." If you are a Java developer, this would be the quickest way to get up and running. It does almost everything you need, but of course, you would have to modify  Moblogger to plugin your markup processor and post/publish logic.
  
  
• The custom blog approach: start with an open source weblogging package that supports weblogging via email, hack it so that it can subscribe to your mailing list and can understand your email markup language. There are a couple of disadvantages with this approach; it limits your choice of weblog software and requires you to pay for an ISP to host your own weblog. The first two approaches use the standard Blogger API to communicate with the weblog server, so they can be used with just any blogging software or blogging service.

Any other ideas? Has anybody implemented this type of system before?

Roller 0.9.8.1 is just a bug fix release. Change-list, source, and binaries are available on SourceForge. Thanks to everybody who took the time to submit a bug and to Atlassian who helped us manage the issues. Don't forget: report JRoller account and sys-admin issues to the JRoller JIRA and report Roller Weblogger bug reports and enhancement requests go to the Roller Weblogger JIRA.

I finally got around to reading Rod Johnson's Introduction to the Spring Framework on The Server Side and that inspired me to read the Rod Johnson interview.  I also read Patrick Peak's Dueling IoC post comparing the Inversion of Control support in the Spring and WebWork2 frameworks and some interesting comments on Matt Raible's Web Frameworks - which one should I learn post. Looks like there are some very useful things in Spring, but without actually using it, it's hard to tell whether Spring is a cohesive and elegant framework, or a hodge-podge of book examples and helper code for AOP, IoC , MVC, and JDBC. It did, after all, start out as example code for the book Expert One-on-One J2EE Design and Development. Spring deserves further study and because Springs features can be used a la carte (as demonstrated by the days old Struts Spring project), learning about Spring could pay off even for existing applications.

I also read Mark Pilgrim's excellent new XML.com column The Atom API.  The column reviews the history of weblogging APIs and then provides details of the new Atom API. The article makes it pretty clear that the Atom API is a better solution than the XML-RPC based Blogger and MetaWeblog APIs. It is easier to implement and it takes advantage of XML features like namespaces and schema. Atom is simple and elegant, yet it remains SOAP compatible; a great example of a web services API.

In other weblogging tech news, two competing proposals for website newfeed discovery have appeared: FDML from Sam "it's just data" Ruby and friends and shortly after that myPublicFeeds.opml from Dave "it's just an outline" Winer. These proposed standards could be pretty useful to sites like Java.blogs that aggregate multiple blogs and JRoller which host a community of blogs.

I spent a lot of time last week painting fishies and even more bubbles. I might just have to bid on the table myself.

<img src="http://www.rollerweblogger.org/resources/roller/fishies.jpg" alt="fish that I painted" /> <img src="http://www.rollerweblogger.org/resources/roller/fishtable.jpg" alt="fish that I painted" />

Any similarity to Disney characters past, present, and future is purely coincidental.

Simon Brown: I must admit that while XDoclet is very useful when building EJBs, I'm not sold on the idea of using for the web tier myself.

Like Matt and Erik, who both left comments on Simon's weblog, I'm sold on XDoclet for the web tier, for generating struts-config.xml, validation.xml, web.xml, form beans, etc.

Larry O'Brien: But what really proved .NET's value proposition to me was when I saw how the subsystem was integrated. Web services may be a buzzword in semidecline, but when you witness the ease with which minimally experienced server-page programmers can successfully participate in developing a scalable distributed application by consuming Web services developed by more experienced programmers, you become a believer.

Found via SBC's weblog. Larry O'Brien sees the multi-language aspects of Dot-Net as a way to enable programmers of different skill levels to work together.

Monologue aggregates weblog entries from Mono bloggers, all 10 of them. That is a nice start.

Ben Maurer In that spirit, I make a plea to the Open Source community: please, please, think about other platforms. In the end, making your software not run on Mono will just hurt both projects, helping no one. I realize for a Windows developer who has never programmed for Linux writing with compatibility in mind does not come naturally. If there is enough community demand, I would be happy to write some guidelines and pointers for software authors to ease this process.

Can Dot-Net developers be convinced that cross-platform portability is important? I'm not talking about "it runs on Windows 2000 and Windows XP" type portability, I'm talking about the real deal. Sounds like a hard sell, doesn't it. Most Microsoft devotees seem to believe that "cross-platform is a silly concept that only works on paper." And don't forget, Microsoft is the company that made it so easy to build non-portable applications with Java that the Justice Department ordered them to put warning popup in Visual J++.

Maybe Mono and Linux will succeed where Java and the Java platform failed. They will finally make convince Microsoft and Microsoft developers that cross-platform works, or at least the Windows/Linux part, and is no longer just a silly concept. There is some evidence of success. Ben Maurer of Ximian has been working on porting Dot-Net applications to Mono and hasn't thrown up his hands in frustration quite yet. Jason Alexander is working the evangelism angle and urging Dot-Net heads to be Mono Aware. As Jason Alexander's co-star might say "good luck with all that."

Update: due to my sarcasm and poorly chosen words, at least one person did not get my meaning. I certainly don't believe that cross-platform portability is a silly concept. I made some changes indicated by strikes and underlines above to try to clarify my point.

<a href= "http://www.usnews.com/usnews/issue/031020/usnews/20black.peo.htm?track=rss"> Jack Black: I am going to do an exercise book. You shouldn't exercise. It's like you don't want to put too many miles on a car; why would you want to put a lot of miles on your body? Keep it in the garage, cover it with a tarp.

Joel Splodsky has written an excellent <a href= "http://www.joelonsoftware.com/articles/Unicode.html">summary of unicode and character sets. Email it to all of your co-workers right now.

Finally, some help for newbie JRollers.

<img src="http://www.rollerweblogger.org/resources/roller/jrolling-handbook.png" alt="image of Joint Rolling book" />

Jon Udell, Why Mozilla Matters: The pros and cons of the browser's always-connected page-refresh model are well-understood. Zero-footprint, cross-platform ubiquity is the upside, a clumsy UI tied to a Net umbilical cord is the downside.

People seem to understand the need for XDoclet code generation in the EJB world where there is a lot of boiler plate code and lots of ugly deployment descriptors to be written, but I've had a harder time convincing people to use XDoclet to generate web.xml, tag library descriptors, and Struts configs.

My coworkers understand the Servlet specification and they know the details of the web.xml DTD, so they see XDoclet as just another quirky tool to be learned. It seems to get in the way, it has bugs, and it is not always updated quickly enough for folks want to use the latest stuff (Servlets 2.4 for example). Learning to use the XDoclet tags is not all that difficult, the open source allows capable programmers to make bug and enhancements, but this is not very reassuring to folks who just want to add another Filter Mapping to web.xml, right now, damnit.

I've gone a couple of rounds with folks discussing pros and cons and I forgot the most obvious argument - continuous integration. The best reason to use a tool like XDoclet to generate web.xml, tag library descriptors, Struts configs, and other goodies is refactoring. If you have a bunch of Servlets, JSP Tags, and Struts Action classes in your code and you want to refactor your code by renaming classes and moving them between packages then you will have to carefully edit web.xml, your TLDs, and your struts-config.xml to correct all of the changed class and package names. If you were using the XDoclet @servlet, @jsp.tag, and @struts.action tags you would have no worries - all of your deployment files would be auto-magically updated.

Rumor has it that Eclipse 3.0 M4 will be released shortly and that a JSP editor will be included. Update: it is out now and the new feature list looks good. Another update: Werner Ramaekers provides a nice  summary of the new release.