Thin or Thick Client [was] EPP [snip]
plug-devel@lists.PLUG.phoenix.az.us
plug-devel@lists.PLUG.phoenix.az.us
Mon Mar 14 13:03:02 2005
I agree with what you have to say, however I believe it should be viewed in a
technologically neutral manor (I see LAMP mentioned again ;)
First, I firmly agree with your requirements comment. We should be much more
flexible, but we still need goal posts and a clear path to follow. Sort of it
does not need to be laid out in feet, or yards, but it still needs to be laid
out.
Second:
N-Tier means many things to many people. I think it is the division of
functional models, that are then further divided into Data, Logic, and
Presentation layers.
I relies that as programmers it is difficult to divorce our selves from the
building blocks of the app, but remember what we need first to come up with
the high level design (Architectural Drawings) and then fit the low-lever
design to match (Engineering drawings). As long as we see the different
phases as additions in the high-level and adhere to it in the low-level, the
we should have no problems.
(I may have miss understood this, but)
As for LAMP, as a data center, why not use MySQL, as for Thin Client, why make
the server and net work so hard? Thick clients or DDA's (Data Divorced
Applications) are just as viable solutions We have not even agreed to what
the functionality should be yet, let alone built a high level model on how
that functionality is to be divided up.
These are just my 2 cents
And may be way off the mark
On Mon, 14 Mar 2005, Trent Shipley wrote:
> 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
> _______________________________________________
> PLUG-devel mailing list - PLUG-devel@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
>