Thin or Thick Client [was] EPP [snip]

[Trent Shipley]

1) First in terms of EPPP, we juniors are operating under the Gordon-Sinclair 
Sofware Requirements Scepticism.  Software "Engineering" inherited 
requirements from other, less plastic, engineering disciplines.  For example, 
in civil engineering requirements are REALLY requirements.  Dams must not 
break and bridges must not fall.  The same is _seldom_ true of software 
requirements.  In the main, software requirements exist to reduce business 
risk.  On a fixed price contract the vendor can stop a pushy customer.  On a 
cost-plus contract a customer can stop gold plating.  In any event, 
requirements show moving goal posts.

I have to agree with Gordon-Sinclair.  For most software project _per se_ 
requirements are, at best, a necessary evil.  Since EPPP lacks strong 
customer-vendor political economics, can move goals and schedules at will, 
and is not producing safety critical software, EPP should not be based on 
requirements.

Nevertheless, like any project, it does need goals, structure, and relevant 
grounded business research.

Right now, our armchair expectation is that the consumer base will want 3 
modes of operation.

1) Typical small user.

Put EVERYTHING on a laptop or desktop.
This user will be confused if EPP does not seem to be a 1-tier workstation 
solution.

2) Walt Disney enterprise.

Put stuff on a highly managed intranet.  This user wants to see an n-tier 
solution with lots of application management options.  For most internal end 
consumers, they prefer a thin client.  Some functions may show up on public 
internet sites (like reservation or ticketing systems).


3) Walt Disney power user employee.

This user wants to use EPP functionality offline from their laptop, but also 
wants to dock and work with the corporate intranet.  (Application level thick 
client.)

==========

I have seen this done before.  What my seniors have done is to EITHER throw 
out the thin or thick client solution for #2|#3 (this is no longer 
technically necessary).

More importantly, for #1 they do just what you object to in my earlier LAMP 
proposal (admittedly based on a miscommunication with JS).  Namely, they 
create LOGICAL objects in the topology.  All objects communicate by TCP.  
Then you build an autoinstaller for case #1.   The autoinstaller installs the 
same parts that it would for case #2, but in a least-common-denominator 
default mode for case #1.  Thus, case #1 is still an n-tier system, it uses 
up A LOT more resources than a progam designed to run as on workstation (but 
that is OK, the workstation has plenty of power for the code bloat).  As long 
as the consumer is satisfied with the default install all is well.  The 
consumer can think of what is really an n-tier topology as a 1-tier 
workstation application.

But both Brian and Joseph have said that they do not want to do what was 
described in the above paragraph.

<point>
I am still not satisfied that you satisfy case #1 && case #2 && use a single 
integrated architecture && not simply resort to the unaesthetic but obvious  
solution of case #1 as a trivial instance of case #2.
</point>

On Monday 2005-03-14 11:19, Bryan.ONeal@asu.edu wrote:
> With quality N-Tier logic, you should e able to move the data to either a
> central point, or a local point.  I know people who will demand both, as
> such we should keep booth outcomes in mind during the designee.  And while
> the high-level design should be independent of the low level design, it can
> be hard for programmers to divorce them selves from the tech during the
> high-level design (Architectural drawing), as they will want to use what
> they are familiar with in creating the low level design (Engineering plans)
>  But that would be the point in gathering all requirements and ensuring
> that each phase of design dose not make the next phase more difficult then
> it needs to be (Such as using LAMP)
>
> On Sat, 12 Mar 2005, Trent Shipley wrote:
> > On Saturday 2005-03-12 14:04, Joseph Sinclair wrote:
> > > Trent Shipley wrote:
> > > >So it is an application designed to minimize the load on enterprise
> > > > sys admins.
> > >
> > > The WebStart-like technologies allow the developer to build an
> > > application for local use without worrying(much) about the network,
> > > while allowing the deployer/packager to easily manage changes and the
> > > deployment of fixes without user interaction required.
> > >
> > > >When do we need to cross this bridge?
> > >
> > > When someone requests the offline/near-line client capability and
> > > someone volunteers to build that functionality.
> >
> > I'm with Bryan.
> >
> > I expect that user scenario will come up fast.  As soon as I talk to an
> > independent wedding planner, campaign manager, or what have you, they are
> > immediately going to tell me that they want to run the application on
> > their laptop.  MAYBE they will want it on a desk top and a lap top that
> > they synch up on occasion.
> >
> > What are the trade offs?
> >
> > Can the same tool satisfy an independent promoter and run on the intranet
> > of Walt Disney's theme park division?
> > _______________________________________________
> > PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
>
> _______________________________________________
> PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel