SSiS Documentation: Design Philosophy

1. KISS: The system is, and has to be simple. This cannot be bloatware without massively increasing the work, as we do not want to have to rewrite every client application that a user may want. SSiS is about the lowest common denominator. The only client application we are developing as part of this project is the PHP interface, and this is primarily because we need it as a test tool. At the point of writing this document, the lowest common denominator was the Palm-type PDA databases, there has formed a large part of the design of the system.
2. Data Formats: We aim to support ALL common formats, up to a point of diminished return. Ideally, we will establish a two way synchronisation applet for each protocol or format. In some cases this may not be practical, and we will simply do a compatible export. Some applets will be user triggered (such as a PDA sync), and some may be triggered by a cron job (e.g. every 5 minutes).
3. Target Audience: The system is primarily a small business groupware tool, and will not re-invent the tool. We aim to provide something that DOES NOT EXIST, a single point of storage of data that replicates itself across many systems. We do not know how large this system can scale. At the moment it looks like the limiting factor may be the number of records and ID numbers held in a single Palm-type PDA.
4. Security: The design is not meant to be "secure", as some of the data systems we intend to interchange data with are not secure either, and therefore will always be a weak link. There have been design considerations. There is no need for a user to have an account of the box, as it is designed to be a "virtual user" system. If network hotsync is not needed, (or can be firewalled off to known and unforgeable addresses) then the system may well be considerable safer, but please do not assume that this box can survive on an insecure network. A certain amount of User trust is needed.
5. Look & Feel: The "look and feel" of the web interface may appear to leave much to be desired. If that is what you think, you may be missing the point. This is primarily a database server, not a client interface. Having different "skins" and pretty icons simply means that people with text only viewers get less support. However, this is not to say that at some point in the future we won't roll out a pretty web interface with Java or rollover graphics, but it would be as well as, rather than instead of, a basic HTML subsystem.
6. Languages: As mentioned above, the current PHP interface is meant to be a tool, not a client interface. Translations at this point would only serve to deflect programming time away from the main project. However, it is probable that we will add a translation database table to the system in the future, which could be used not just for a multi-lingual company needing to have accurate translations of technical words to hand, but also for any interface tool. This part of the project may be forked off, and developed as a stand-alone system, such as the one that we helped put in for the IP-Cop firewall project.