What's it all about, Alfie?

I have to admit that I don't like debugging code that isn't mine. In fact, it's one of the most frustrating things I can think of. You are stuck between the users of the software and the vendor and neither is really capable of giving the other what they are needing at this moment. The developers want detailed stack traces, detailed information about what was being done - something that makes it more repeatable. Users just know it crashed and they didn't necessarily start it in such a way as to get this information because they didn't think that it would crash.

So to the developers I have to say "Hey, this is what I have and I know it's not much..." and to the users I have to say "OK... I'll let them know" but in the end, there's not really a single thing I can do other than to try and replicate the problem myself in an environment that I can get the necessary information from the application for the developers.

What I really want is the source code so that I can look into putting more advanced features that might make it a little easier to figure out what happened. Alas, that's not possible, and I'm stuck being in the middle. Not the best place to be to really help with solving the problems, but if that's the only place to be, there isn't a lot of choice.

OK, in the saga of the FTP SSL/TLS problem I've come to a wonderful find. FTPeel from Freshly Squeezed Software in FL has an SFTP, FTPS, FTP client that looks as nice as Transmit. It doesn't have the "your stuff"/"their stuff" two-pane approach, rather it has a single view on the remote data that you can download, edit and upload. It's clean, simple, and works perfectly well with Comcast and that's all I need.

Seems like a lot of digging to find this, but now that I have, I'm an owner and that means great upgrades, etc. Gotta love that.

I started using networked computers in college in the Fall of 1981. OK, it's been 20+ years, and I'm still using them, but hey... I've got experience. 🙂

As I was saying, back at Purdue I used the amazing tools - ftp and rn. Yes, this is when the Internet was called the ARPAnet and ftp was considered safe because there weren't script kiddies and most of the users had their own systems to admin, and they all existed on a mutual trust system. Alas, that's not possible anymore. Anyway... I would get files from remote ftp drops without a search engine, without the web. But the newsgroups functioned as message boards as well as places to find things organized by category. It wasn't perfect, but it was wonderful at the time.

It was always true that certain newsgroups had higher signla-to-noise ratios than others, and when AOL came online with the newsgroups a lot of folks ban lists included AOL. But there were still folks that preferred the groups to the newly created web-based message boards like Slashdot, etc.

I liked to keep up with the groups, and recently I've gotten tired of the crummy newsgroup service from Comcast and decided to try something different. The guys at Panic created Unison a next generation news reader and provides a news service for it as well. Since I was tired of bugs in the code I was using and liked the things I've used from Panic in the past, I decided to give it a whirl.

I'll say that it isn't perfect, but for a 1.0.2 product it's pretty darn nice. I like the basics, and while there are a few things in the UI related to navigation that I'd like to see - or at least know were there if they were already in the application, it's nice and solid. Also, one of the things I know of Panic is that they update their software when they find things to fix/add. This means to me that it's only going to get better.

Everything old is new again... gotta smile at that.

OK, good news. The latest version of NetFinder seems to know about FTPS, which is what the protocol is called when FTP does SSL/TLS, and does the connecting automatically. This is good news because I now have at least a functioning secure uploader for the time being. Hopefully, Transmit will add this if it's not already in the works now.

Interestingly, I had a hard time figuring out that NetFinder did this because the documentation was pretty darn bad. That is to say, the documentation that came with the program. When you go to their web site, the docs are quite good and complete - which is where you learn that SSL/TLS is tried automatically and if it's successful, a small locked padlock is shown at the upper right corner of the screen. But to figure that out took me a while.

Maybe I'm slow.

In any case, until something better is found, I'll stick with NetFinder and let is go at that. Whew!

OK, I've become a little more educated today about yet another way for ftp to be transported. It turns out that sftp uses OpenSSH as the transport mechanism whereas ftp on SSL/TLS simply uses OpenSSL. Interesting, but a pain in the rear as I'm trying to find a way to upload changes to my Comcast web pages without using clear-text passwords. In it's infinite wisdom, Comcast has decided to use the SSL/TLS form of securing FTP, and for Windows users, that's probably just fine. But I'm on Mac OS X, and there aren't a lot of SSL/TLS clients out there.

In fact, a Google search said that several clients for Mac OS X were capable of dealing with SSL/TLS, but when I tried them I was unable to get any of them to work with the Comcase upload site. Now there's certainly a possibility that the port number I'm using is wrong. In one client it allowed me to set the port number but defaulted to 990. Interestingly, there's no mention of a port number on the Comcast web site for SSL/TLS. Why should there be?

So I'm left with the email I sent to Panic.com - makers of Transmit, the ftp client that I like to use (and have purchased) for Mac OS X, and we'll see if they come back with anything helpful to try. One source listed Transmit as an ftp client that did SSL/TLS, but I've yet to be able to prove that with the program in hand.

It's an interesting thing, building better software.

I've finally gotten a first cut done at the application that will allow me to make journal entries a lot easier than before. This is a little Cocoa app that runs on Mac OS X and uses XML-RPC to communicate with the server that hosts my journal. It's interesting that there seems to be a hit-n-miss nature to it working from certain access points, but that's probably as much the access as it is the software. I'm sure it could be more reliable, but as long as it connects and does the job, I'm happy.

I have completed the first few tests and things are really looking up.

OK... one of the things that I've been trying to do over the last few days is to create a new mechanism for uploading and editing all the entries in my journal. Since I've put everything behind a router/firewall, I don't have easy access to all the ports of the server, and that's good, but also it limits what I can do in terms of creating a client for the Journal.

I remembered XML-RPC as one simple implementation of a remote invocation system that's transported completely on top of the web server's port/protocol. This then, would be ideal - since I have all the machines' web servers opened up through the router, and with XML-RPC I have the choice of platforms to write both the client and the server. I decided to go with PHP for the client and a native Cocoa app on Mac OS X for the client.

The choice of PHP for the server seems like a good one. I have all the database connectivity I need and the methods that I'm creating are small and pretty fast - even on the hardware that I'm using. I will admit that the docs were a little thin, but it didn't take more than a few hours to get my server running. Interestingly, I didn't know that it was running until I put the client together.

I have to hand it to Apple - they have put together some of the greatest tools I've ever used. In Jaguar (10.2) they had an implementation of XML-RPC in AppleScript and while it had problems, it was still there. Thankfully, the guys at Ranchero created another XML-RPC implementation for Jaguar that didn't have these issues. When I checked their latest Cocoa documentation pages, it seems that Panther (10.3) has a better XML-RPC implementation built into it. So I used that.

There were several issues with getting the data passed back to the caller - most notably, that the PHP arrays can't be passed as arrays in XML-RPC, at least not in the implementation that I got. They end up getting passed as associative arrays/structs and in Cocoa that's NSDictionary objects. Not obvious and certainly the most difficult part of the project. Once I knew what the data really was, iit was a simple matter of matching things up. Yet there was still one more problem.

While at work, I have a standard internet connection - meaning a DSL line behind a router providing NAT, etc. When I try to hit the web site as a simple web site the browser never really renders the page. If I use telet to the right port, the data comes back just fine. This means that the connectivity to the host is fine, it's something with the browser - in this case, Safari 1.2. Since the XML-RPC service is also based on the core web services that drives Safari, it's not surprising that it hangs as well. Very strange.

The result is that the reason for the creation of the server and client is is part of the problem. If I'm at home, then there's no hanging and no problems. Also, I can easily SSH from work to the box meaning that not all the tools/services are effected. A simpler solution may be to create an X11 app and then SSH into the box and run the app there. Seems sort of silly as text files work just fine. So maybe the solution is a few scripts that send and upload the files. Seems like if SSH is solid it'd be easier to do that, but it certainly isn't as interesting and fun as making the client/server work with some kind of protocol.

We'll have to see if I get any clues as to why this is happening and if it's even possible to clear this up. Looks kind of doubtful right now.