I agree with Jervis, things just running out-of-box is much nicer for first time users than having to fiddle about editing config files.
Would an alternative be to change the structure of the samples and move these technology specific samples into the extension that they use. For example, something like having a javascript folder that contained separate projects for the JavaScript container and each JavaScript sample. There would still be lots of helloworld samples, but not all in the one top level samples folder so wouldn't be quite so in your face. ...ant On 8/17/06, Liu, Jervis <[EMAIL PROTECTED]> wrote:
One thing concerns me would be the out-of-box user experience. For a first time Tuscany user, don't you think it is more user friendly if users only need to follow the readme, go to a directory, run a common, then everything works out-of-box? Speaking in my experience, it does encourage me to explore a new product further if I can set up and run a typical helloworld sample successfully in 5 minutes without any coding. Well, maybe just me being too lazy... ;-) Cheers, Jervis > -----Original Message----- > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 17, 2006 6:54 AM > To: [email protected] > Subject: Sample framework > > > We have had a rapid increase in the number of samples recently many > of which do essentially the same thing. Some feedback from M1 also > said that we seemed to have invented the greatest number of > varieties > of HelloWorld but that it was hard to tell if SCA could do anything > else. I'd like to propose a change in how we structure the > samples so > that we make it clearer to illustrate the technology to users. > > Rather than having separate projects for each technology > variant, I'd > like to suggest we have just a couple of projects that provide a > framework and then have instructions in the documentation for each > technology that clearly show how to apply it. > > For example, I can see two framework environments: > a) a client environment with a simple command line client wires > together a couple of local components > b) a webapp environment with a simple JSP client that also wires > together a couple of local components > > Then, for example, the JavaScript extension could say: > To illustrate the use of JavaScript as a component, take the > client a) and > 1) replace <implementation.java class="Foo"/> with > <implementation.javascript script=" foo.js"/> > 2) Install javascript extension > 2) rebuild/run sample > > Or, to illustrate the WebService binding: > Server > 1) Take webapp and add <service>< binding.ws ...> > 2) Install Axis binding extension > 3) Deploy server app to Tomcat > Client > 1) Take client application and replace <component name="foo" ...> > with <reference><binding.ws ...> > 2) Install Axis binding extension > 3) Run client > > The basic idea being, have a common framework and the > instructions on > how to use the particular extension. > -- > Jeremy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
