Some more thoughts
After few days spent on researching the API of Blinksale and Freshbooks, I am certain I’ll have to choose only one of them for the first implementation of sInvoicer. This is because I would move more slowly if I would try to do both in parallel. And because I would have to write something like a Proxy Server to support Freshbooks, Blinksale seems to be easier choice. I would need to use something like proxy for Freshbooks because they require a static IP address for every account that has API enabled. That means that I would have to transfer all requests from clients using sInvoicer over my server to Freshbooks and then other way around; from the Freshbooks server over my server to the clients. This is even not so bad because I would be able to track the usage of sInvoicer. If in the requests from the clients I add also my license key, I would have exact info and much more control over licensing. I would know exactly if a license that has only one client is trying to connect twice in the same time from 2 clients and prevent that. But, as for the first version this seems like overkill.
So, my decision now is, I will go first with Blinksale implementation. I will try to make it public as soon as possible, and if there is interest at all, I will start on Freshbooks version. Then I will be able to redo also the Blinksale protocol to go over my own server, so I’ll have more control over the licensing. But, as I said already, I’ll leave this for later.
Now, little bit from the technical perspective. I plan to make separate DLLs for every such provider, and keep the implementation details in there. I am thinking on a model where the main EXE file will know only about the raw interface of the underling protocol. I will use something like Factory in COM for creating the actual objects. I don’t have this 100% cleared, but I am sure I’ll have in the main EXE as little specific dependencies as possible. Let’s say, the code in the EXE will know what a Client is, but it won’t know where it goes to read the Client info, or how it writes the changes. I’ll do this by instantiating the specific object (Client, Invoice etc) in the specific DLL from a raw interface known to the EXE. As an example, to download all Clients from a Blinksale account and store them in the local database, I would instantiate a read protocol for Blinksale and write protocol for local database. That way, code in the main EXE will collect all Clients with a single method, and than calling Save in a loop for all Clients. Other way around will push the local changes to the specific Blinksale account. Of course, this is too simplified; I will have to resolve all synchronization issues that may arise, but one at a time.
I was also thinking on putting some draft versions available for download as soon as I have something usable, so I can get feedback from potential users early in the development phase. But, I am not yet sure is this a good idea. Anyway, I don’t have anything ready yet, so decision can wait a bit.
