Re: Sample framework

[Jim Marino]

On Aug 18, 2006, at 6:10 PM, Robbie Minshall wrote:
Regarding whether or not to embed tomcat with the muscle car  
application
. . . it is definately just going to come down to a preference  
issue for
ease of deployment vrs an idealistic build env ( are we teaching  
people to
deploy, or are we providing an easy avenue for one to showcase SOA  
using SCA
& SDO - that is the nuts and bolts of the difference here ).

I have the feeling I my previous post didn't explain well...I don't  
think we are trying to teach someone how to deploy a war or some type  
of archive. I think the goal of the samples should be to teach a  
fairly skilled developer how to write applications for the SCA Java  
runtime.

In order to teach a developer how to use Java Tuscany, they need to  
have the sample source and an easy to use build environment. Just  
deploying a binary to a server and watching it run isn't really  
helpful. If we take some of the more popular frameworks as guides,  
the samples they come with are distributed as source with a build  
environment and a minimal bootstrap (in the case of Hibernate), if  
anything at all. To take a few:

http://caveatemptor.hibernate.org/2.html
http://www.springframework.org
http://ibatis.apache.org

We can structure the sample build to resolve dependencies through  
maven and not have to manage those as part of a distribution.  
Moreover, the build can include multiple goals for different target  
hosts. Deploying to something like Tomcat or a Servlet engine would  
be a simple process of doing something like:

1. Download the sample tar, unzip it
2. Run mvn war
3. cp <war file> <tomcat deploy dir> (or just run the standalone  
Tuscany version)

To set up a build environment with all dependencies:

4. mvn idea:idea (or mvn eclipse:eclipse)
5. Add the project created in step 4

To create a full debug environment:

6. Download the tuscany core and extension source tars
7. Attach source to the project dependencies in the IDE


My view is
that the working tutorials should be educational and the killer app  
should
be distributed in a manner that is easy for exec/manager types as  
well as
developers to get going right off the bat
Hmm, I would say our primary audiences (in order of importance are):  
systems developers who want to contribute to Tuscany; and  
applications developers who want to use it. I think it is a bit of a  
stretch to say execs/managers would bother to download Tuscany.

I agree though it is important to get developers up an running as  
quickly as possible with something useful. Given this, do you think  
the steps I outlined above are too difficult for a developer to do,  
particularly the "average" developer who uses open source (who is  
really above average and used to tinkering with things)?


- though I definately see the
other side of this argument.


Regarding the 'sending the message that people should use SDO/DAS
instead of O/R technologies such as Hibernate, EJB3, or JDO. How
about showing how they are complimentary'
. . . the issue here is that the role and benefits of SDO/RDB DAS is
somewhat grey at the present moment.  It is clear that providing a  
good
document show casing the expansion of existing applications using  
Hibernate
and a POJO model into a service orientated SCA land using the SDO
functionality across services is key - this is the complimentary  
part and  I
could not possibly agree more ( why Kapel and I are playing with a  
Hibernate
DAS ).
This would be really cool, for example allowing Hibernate graphs to  
be sent to a client. The OpenJPA people also expressed interest in  
this and I'd be happy to introduce you to some of them if you are  
interested.

. . . it is also very important for us to have a competitive  
picture and
story regarding using the RDB DAS for persistence rather than  
solutions such
as Hibernate/EJB3 etc - this is not so simple and would involve best
practices regarding the various performance aspects and the  
disconnected
graph vrs connected model.

This is my own opinion (I mostly like Hibernate even though it has a  
few quirks) but I really don't think we want to position SDO/DAS as  
competitive to JPA or Hibernate. We would gain more traction if we  
worked with popular O/R tools such as Hibernate as instead of  
attempting to replace them.

The samples should address two perspectives:  How do I best migrate my
application using existing technologies into a SOA application ; If  
I am
starting from scratch what is the most common, and therefore the most
supported technique for model, persistence and exposure.

I'm not sure about SDO but one of the key themes of the SCA  
collaboration is that SCA can use *existing* technologies and it does  
not force people to re-write their applications. Of course it's not  
magic and people need to architect things in a service-oriented way  
to do this, but the key point is the amount of re-writing is kept to  
a minimum. My own preference is to be really cautious about this  
since if people perceive SCA as yet another technology that is going  
to force them to redo everything we are going to have difficulty  
gaining traction.

Jim

Robbie




On 8/18/06, Jim Marino <[EMAIL PROTECTED]> wrote:


On Aug 18, 2006, at 12:24 PM, Robbie Minshall wrote:

> I think that there are two ( ok more than that but still . . . )
> types of
> samples.  One type attempts to demonstrate the muscles of the
> technology and
> inspire a 'boy this is great, this is better than what I am
> currently doing'
> thought process.  The other is more educational and attempts to
> walk the
> developer through the development/deployment process while giving
> them a
> sense of what they are accomplishing.  Both are usefull.  However,
> I often
> feel that samples get the goals confused and wind up complicating
> the code
> of educational sample without providing the appropiate tutorial
> updates.
>
I agree. Petstore is probably an example of this happening.

> The key for educational samples is that they should be readable,
> should
> involve deployment and most importantly a concise accurate
> tutorial.   They
> should not attempt to be the killer app but in the SCA land should
> definately involve plugging in different service implementations
> etc as a
> part of the tutorial.  It is also a little harder than one would
> think to
> provide documentation etc that clearly indicate to the user which
> application they should use for what goal.
>
I'm not sure the education samples all need to plug in different
impls. Maybe as an "extra". For example, I may only be ever
interested in writing Java. Agreed on documentation.
> I would recommend two approaches.  Providing a simple sample
> application
> combined with a tutorial for dev, deployment, execution, service
> replacement
> etc that does not provide an runtime environement such tomcat.   
Also
> providing a fatter muscle flexing sca application combined with a
> up and
> runing environement.
Agreed on the division but I don't think we need to distribute a host
environment such as Tomcat. For the muscle flexing one (I know have
an image of some 70s muscle car, maybe we can call the sample
"chevelle" ;-) ), I think the only practical environment would be
standalone or OSGi since J2EE is going to constrain us too much.
>
> On an aside I am currently working on a simple POJO Hibernate
> application
> conversion to using SDO and then exposing services via SCA.  Kapel
> and I
> plan to write a simple tutorial going over the migration and other
> aspects
> of this task such as comparing a Hibernate RDB DAS to the SDO DAS,
> and hte
> performance cost of using static SDO within our applications POJO
> model.
>
Hmm, that kind of sends the message that people should use SDO/DAS
instead of O/R technologies such as Hibernate, EJB3, or JDO. How
about showing how they are complimentary as I think they really
address different use cases?


> . . . thoughts ?
>
> Robbie
>
> On 8/18/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>>
>> I think there are a couple issues here which would benefit by
>> stepping through what we expect users to actually be doing. From a
>> user standpoint, I imagine most people will have the following  
goals:
>>
>> 1. Figure out how to write an SCA application
>> 2. Figure out how to deploy the application
>> 3. Run the application
>>
>> Starting with 3 in a server environment does not really do  
anything.
>> For example, I start something up and hit a web page, but can't
>> really debug or step through without setting a project up in my  
IDE.
>> What I think most users want is a quick way (i.e 5 minutes) to  
do the
>> following:
>>
>> 1. Download a sample that has an automated way to create a dev
>> project
>> 2. Build the sample and deploy it to whatever host environment I
>> typically do my development with. For example, for web app
>> development, I prefer Jetty since it is light, fast, and easily
>> embedded. Others may prefer Resin, Websphere, WebLogic, etc. As I
>> mention below, however, I don't think most Tuscany development  
will
>> be done inside a web app.
>> 3. Run the sample and debug it (either remotely or in my IDE) so I
>> can see what is happening
>> 4. Make changes to the sample and goto step 2
>>
>> The most time-consuming parts I have found in using new  
technologies
>> is getting my dev environment setup properly. For example, with a
>> binary distro, here is what I would have to go through:
>>
>> 1. Download the binary distro, including a pile of dependencies
>> probably totaling over 200MB
>> 2. Unzip the distro, follow the readme instructions to start the
>> thing
>> 3. Use a browser to hit a web page that prints something out
>>
>> At this point, I still can't really see what is going on much  
less do
>> things like changing bindings, adding policy, swapping  
implementation
>> types, etc. If I want to use really understand how SCA and Tuscany
>> work, I would have to:
>>
>> 4. Download the source sample, maybe it is included in 1 but maybe
>> not
>> 5. Setup my dev environment with a sample project
>> 6. Build the sample and package it
>> 7. Figure out whether I want to deal with Tomcat the version of
>> Tomcat my Tuscany download just came with. Probably not, since I
>> already have a Tomcat install or use something else.
>> 8. Make any necessary changes to my dev environment so I can debug
>> the sample as it is run
>> 9. Deploy the sample to the host I do my development with
>>
>> IMO what would be much simpler for end users would be to:
>>
>> 1. Download a sample distro
>> 2. Build it with maven, which can generate the IDE project for  
me as
>> well as deployment artifacts for whatever host type I choose,  
e.g. a
>> WAR file
>> 3. Set my IDE to use the source from the sample I just downloaded
>> 4. Decide where I want to deploy it to. If it is a WAR, I just  
drop
>> it in and either run it from within my IDE and debug or attach  
to a
>> remote process
>>
>> I think it would be useful to look at projects that have been  
highly
>> successful (i.e. one of the most widely used Java projects) and  
see
>> how they do things, Spring and Hibernate. Both do not ship a pre-
>> configured host environment.
>>
>> As a further thing to think about, I expect most SCA users will  
*not*
>> be developing with or deploying to Tomcat and will probably  
instead
>> use the standalone version. This is for a number of reasons:
>>
>> 1. The J2EE deployment model restricts some of the most important
>> features implicit in SCA
>> 2. Related to #1, most of the capabilities people really to  
want to
>> see involve things like transactions and policy, dynamic re- 
wiring,
>> etc. which are not directly supported in Tomcat. This will mean
>> either having to configure Tomcat with a transaction manager or
>> bundling one in the web application. Standalone can handle this
>> dynamically. Consequently, I suspect the user experience will  
be more
>> difficult on Tomcat. I also don't think most are going to be
>> interested in "helloworld" variants as that can be done more  
easily
>> with existing technologies.
>> 3. With dependency injection,  there is no need to develop  
within a
>> container - just use mocks. When I build apps, I typically  
don't get
>> them running in a host environment until integration testing.
>>
>> Jim
>>
>>
>>
>> On Aug 18, 2006, at 7:26 AM, Rick wrote:
>>
>> > +1 for both .. does that make 2? :-)
>> > I like the idea of having the bar a low as possible for  
someone to
>> > just start playing with samples to learn building SCA  
applications.
>> > But I also see Jim's point.  There are other set of users (IT
>> > types) that may not even care about Tomcat and we definitely  
need
>> > to please them too.
>> > I think the trick here is to for the site documentation about  
what
>> > download to to satisfy your particular interests  is very  
important
>> > and we make perfectly clear that Tuscany is not just a Tomcat/
>> > webserver extension.
>> > Luciano Resende wrote:
>> >> +1 for what Jervis, Ant and Simon are saying... I really  
liked the
>> >> pre-configured Tomcat  installations available for the  
samples in
>> >> M1, made
>> >> my life much easier to get started in Tuscany. I have also
>> >> recently created
>> >> that for DAS samples and it's available today at samples/das/
>> >> testing/tomcat
>> >>
>> >> - Luciano
>> >>
>> >> On 8/18/06, Simon Laws <[EMAIL PROTECTED]> wrote:
>> >>>
>> >>> On 8/18/06, ant elder <[EMAIL PROTECTED]> wrote:
>> >>> >
>> >>> > There are quite a few old threads where we've discussed
>> >>> samples, here's
>> >>> > just
>> >>> > one of them:
>> >>> >
>> >>> >
>> >>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/
>> >>> 200604.mbox/%
>> >>> [EMAIL PROTECTED] 
%3e
>> >>> >
>> >>> > If we're moving towards multiple Tuscany distributions
>> targeted at
>> >>> > different
>> >>> > areas then i think its fine (and even desirable) for one of
>> those
>> >>> > distributions to contain an entire host environment. One  
of the
>> >>> good
>> >>> > things
>> >>> > about the M1 release was that it really did make it easy for
>> >>> new users
>> >>> to
>> >>> > get started, just "unzip and click on startup".
>> >>> >
>> >>> >    ...ant
>> >>> >
>> >>> > On 8/18/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>> >>> > >
>> >>> > >
>> >>> > > On Aug 17, 2006, at 11:21 PM, ant elder wrote:
>> >>> > >
>> >>> > > > 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.
>> >>> > > I like the idea of moving the samples into the extensions
>> >>> (except
>> >>> > > maybe the samples that use multiple extensions) and  
actually
>> >>> think it
>> >>> > > could correspond to Jeremy's proposal. This would allow  
us to
>> >>> > > compartmentalize things more which I think is going to be
>> >>> fundamental
>> >>> > > to scaling the project. I have several caveats for this
>> though:
>> >>> > >
>> >>> > > - there is a clear distinction in the tree between the
>> >>> samples and
>> >>> > > runtime extension code. In other words, each sample  
project
>> >>> should
>> >>> > > not be a sibling to the project containing extension  
code but
>> >>> should
>> >>> > > go under a samples folder in separate projects
>> >>> > > - the extensions are individually built from the core
>> >>> projects and
>> >>> > > fairly autonomous per my previous email
>> >>> > > - samples are not built with the check-in build for
>> >>> extensions and
>> >>> > > are separately distributable
>> >>> > >
>> >>> > > In terms of end-user experience, I think things are  
going to
>> >>> vary
>> >>> > > greatly depending on the host environment. For example, in
>> our
>> >>> > > standalone environment, things can be automated fairly
>> easily:
>> >>> > >
>> >>> > > 1. User downloads core distribution
>> >>> > > 2. User downloads and drops in sample distribution and  
starts
>> >>> the
>> >>> > > standalone core
>> >>> > > 3. Core reads the dependencies from the sample SCDL and  
pulls
>> >>> down
>> >>> > > the required extensions via the ArtifactFactory from a  
Maven
>> >>> > > repository. This would resolve the transitive closure  
of all
>> >>> > > extension dependencies. This would allow us to track
>> >>> dependencies for
>> >>> > > extension libraries such as Spring for "free" since most
>> >>> projects
>> >>> > > publish POMs to a Maven repo.
>> >>> > > 4. If user chooses, they could avoid step 4 and just  
download
>> >>> the
>> >>> > > extension and plug it in
>> >>> > >
>> >>> > > Something similar to the above could be done for OSGi  
except
>> >>> the end
>> >>> > > user would just deploy a core bundle into an existing OSGi
>> >>> host such
>> >>> > > as Equinox they had installed.
>> >>> > >
>> >>> > > If we are deploying to a servlet container, things will
>> >>> likely be
>> >>> > > more complex but not too much:
>> >>> > >
>> >>> > > 1. User downloads sample application and builds it using
>> >>> Maven, which
>> >>> > > retrieves the core as a dependency and bundles everything
>> >>> into a war.
>> >>> > > 2 User deploys the sample war
>> >>> > >
>> >>> > > If we "prepackaged" every sample distribution so it could
>> >>> just be
>> >>> > > dropped in, I think we will wind up with a ton of  
packaging
>> >>> problems
>> >>> > > as core will need to be included in every one.
>> >>> > >
>> >>> > > I'm pretty firmly against distributions containing an  
entire
>> >>> host
>> >>> > > environment, such as Tomcat. I'd prefer we follow projects
>> like
>> >>> > > Spring, Struts, WebWork, Hibernate (take your pick) and
>> provide
>> >>> > > distributions which are simple to deploy into containers
>> >>> using some
>> >>> > > minimal configuration steps. My reason for this is partly
>> >>> practical.
>> >>> > > First, we should support deploying on a variety of host
>> >>> environments
>> >>> > > and having to rev versions would be a nightmare.  
Second, in
>> >>> most data
>> >>> > > centers I have come across, there is a standard image
>> >>> technologies
>> >>> > > must accommodate and they will not accept an "bundle of
>> stuff".
>> >>> > >
>> >>> > >
>> >>> > > Jim
>> >>> > >
>> >>> > > >
>> >>> > > >   ...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: tuscany-dev@ws.apache.org
>> >>> > > >> > 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: tuscany-dev-
>> >>> [EMAIL PROTECTED]
>> >>> > > >> > For additional commands, e-mail: tuscany-dev-
>> >>> [EMAIL PROTECTED]
>> >>> > > >> >
>> >>> > > >> >
>> >>> > > >>
>> >>> > > >>
>> >>>
>>  
--------------------------------------------------------------------
>> >>> -
>> >>> > > >> To unsubscribe, e-mail: tuscany-dev-
>> [EMAIL PROTECTED]
>> >>> > > >> For additional commands, e-mail: tuscany-dev-
>> >>> [EMAIL PROTECTED]
>> >>> > > >>
>> >>> > > >>
>> >>> > >
>> >>> > >
>> >>> > >
>> >>>
>>  
--------------------------------------------------------------------
>> >>> -
>> >>> > > To unsubscribe, e-mail: tuscany-dev- 
[EMAIL PROTECTED]
>> >>> > > For additional commands, e-mail: tuscany-dev-
>> [EMAIL PROTECTED]
>> >>> > >
>> >>> > >
>> >>>
>> >>>
>> >>>
>> >>> I agree with Ant. As primarily a user (in the sense that I
>> wanted to
>> >>> understand it and try the samples) of the Java M1 release the
>> >>> presence of
>> >>> the pre-configured Tomcat installation was really handy for
>> quickly
>> >>> running
>> >>> through the samples and getting a feel for what it was all  
about.
>> >>> As you
>> >>> are
>> >>> constructing a build and distribution system/approach that  
allows
>> >>> you to
>> >>> cut
>> >>> different distros to suit different requirements for  
hosting or
>> >>> embedding
>> >>> can you make a standalone samples distro for the interested
>> >>> newbie. No
>> >>> suggestion that this distro would get deployed into  
production or
>> >>> used
>> >>> other
>> >>> than to get familiar with the technology or bootstrap a
>> development
>> >>> environment? This doesn't suit the hardcore techy who just
>> wants the
>> >>> latest
>> >>> release of the components they are going to refresh into their
>> hand
>> >>> crafted
>> >>> development/test/deployment environment but then they would go
>> >>> and get one
>> >>> of the other distros.
>> >>>
>> >>> Regards
>> >>>
>> >>> Simon
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>> >
>>  
---------------------------------------------------------------------
>> > 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]
>>
>>
>
>
> --
> * * * Charlie * * *
> Check out some pics of little Charlie at
> http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/
>
> * * * Addresss * * *
> 1914 Overland Drive
> Chapel Hill
> NC 27517
>
> * * * Number * * *
> 919-225-1553


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
* * * Charlie * * *
Check out some pics of little Charlie at
http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/

* * * Addresss * * *
1914 Overland Drive
Chapel Hill
NC 27517

* * * Number * * *
919-225-1553


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]