in reply to Re^2: Choosing a Platform
in thread Choosing a Platform

These still aren't really requirements. I was thinking of something like "handle customization of system functions for individual customers in a way that minimizes our work." Assumptions about using multipe servers, remote methods, etc. are all design, not requirements, and they are affected by your choice of platform.

You talk about code generation as a way to achieve ease of maintenance and avoid "quirky" behavior. In general, code generation is pretty confusing and error-prone, and often makes maintenance harder.

Then you're talking about remote method calls, without any context for why they have to happen. Your first goal should be to eliminate as many remote calls as you can, since they will slaughter the performance of your system. If you do have to do something remotely, that still doesn't mean you need AUTOLOAD (another rather quirky and error-prone feature). You can do this sort of thing with proxy objects, or various rmeote method call systems that different platforms supports.

I don't know enough about your system to give you concrete advice, so all I'm really saying is that deciding you need functionality along the lines of AUTOLOAD before you have chosen a platform seems backwards to me and implies that you really have chosen a platform already in your mind.

Replies are listed 'Best First'.
Re^4: Choosing a Platform
by Anonymous Monk on Jul 26, 2004 at 22:46 UTC

    Fair enough.

    Requirements include, but are not limited to:

    • A single architecture must scale to support 1 customer on a dedicated node (1 or more servers) and several hundred customers on a load-balanced cluster of servers.
    • The database must be accessed only by the application core servers, never by the web servers.
    • One architecture must fit every client. Because this will never happen, the architecture must be extremely flexible and allow customization at every level through method overrides and subclassing.
    • System functions include:
      • Object Oriented content management system for websites.
      • File management, supporting SSL, download logging, permission-based access (see below). Should be nearly as fast as serving static files.
      • User-, Group- and Role-based permissions to view and modify data within the system.
      • Product catalog management, including products, categories, attributes, shipping rates, taxes, etc.
      • Order reporting.
      • Extensible shopping cart system to be included into websites.
      • Each server must run the same version of the system code at all times. Object-definition conflicts could cause loss of data integrity, so an automated software distribution system is very important.
      • The system must support remote administration, possibly via a web-based dashboard.
    • To scale nicely, each piece (GUI, Core, DB, etc) must function well alone or as part of a load-balanced or clustered group. For example, we might have 1 Core server, or 10 Core servers, but they shouldn't care.

[reply]
Re^4: Choosing a Platform
by drago99 (Sexton) on Jul 26, 2004 at 22:48 UTC
    Woops, forgot to log in before I posted.
[reply]

In Section Meditations