Sunday, January 12, 2003

Development with CVSWeb. I've been thinking about CVSWeb and have a few thoughts I would like to share. CVSWeb is a web interface to CVS.  It allows you to browse source code revisions and even shows a line by line comparison between revisions.  Plus it does a whole lot more. If you're using CVS for source control this is one tool that I believe is a must have.  It brings to the table a set of very practical and useful features.  Often I resort back to my source code either looking for references or a piece to copy from.  Sure, I can dig through source code files or even switch between instances of editors but having source code exposed through a web browser is incredibly convenient.  In addition it offers all the nice things a web page has to offer: hyperlinks, favorites, ubiquity, etc. Another facet of its usefulness is team communication.  For example being able to hyperlink to source code revisions.  I could pass source code links between emails or even through instant messenger.  I've communicated with remote developers using this and like it very much.  Another case is for managers or architects.  People who need a bigger picture with the ability to dive deeper.  This tool makes it much easier to do. So we have an incredible tool for making software development better.  But I have a few peeves with CVSWeb.  One is it's a big hairy ball of code.  Further more it's a big hairy ball of Perl code.  I want to add more functionality like sub linking to a specific line of code.  But I do not want to touch it.  I don't have the time or the energy to wrap my head around it.  Another thing is installation.  It may be strait forward to install on a UNIX box but it's sure frustrating to setup on a Windows box.  I have to install Perl and RCS.  Then I've got to go through a bunch of security hoops.  Then if my toes are crossed right I might get a meaningful error message indicating what I did wrong.  So then I might check my cryptic configuration settings.  And then check the antiquated environment variables.  And so on and so on.  Here's a quote I found with ViewCVS (an attempt to make CVSWeb better by porting it to Python): [Perl] combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski I've seen nice Perl code and have nothing against it but that quote pretty much sums up my feelings about it. Here's what I'm thinking.  Using the .NET Framework, build a set of base classes to interpret the CVS source files.  This would expose a nice interface to CVS.  Further more, extend it through web services.  Then with ASP.NET build a fully functional version of CVSWeb. I've started on a quick prototype of what I'm thinking.  I started calling it NCVSWeb.  Right now it's a basic CVS browser with limited functionality. I'm thinking of making this a full blown open-source project similar to NAnt and NUnit.  This would be my first attempt at such a thing.  I would appreciate feedback on how to get started.  In addition would anybody else like to contribute??   [StronglyTyped - Richard Caetano's weblog on software development] 9:39:16 PM    comment []

RSS based APIs. Matt Croydon: Translating that into an XML-RPC call hurts my head. That's because the MetaWeblog API doesn't specify how to deal with required attributes.  Or with namespaces.  Or with nested XML elements...  Of couse, one could one by one address these items, and in the process reinvent XML. For reference, here again is a RESTLog post for this item.  Now here it is in XML RPC, with the troublesome attribute included as a comment.  Finally, here a hypothetical SOAP version, with the blogger API defined control parameters passed as a SOAP header. IMHO, if one can find a way to work with transfer level authentication and authorization, one should.  If application level control information is required, then an alternate header mechanism may be appropriate.  And this need not totally be an either/or situation.  One can use transfer level authentication and authorization with SOAP.  Ideally, the blogid would not be a parameter, but would be included in the URI.  Things like that. And, again, the offer is open: if consensus were reached around a weblog post API which either wrapped or subsetted (or both) RSS 2.0, I would work with others to provide the validator. [Sam Ruby] 9:38:32 PM    comment []