Re: [5.0] Cluster features

[Henri Gomez]

Remy Maucherat wrote:

Hi,

I think the clustering features in Tomcat 5 should get an overhaul.
Despite some licensing dicrepancies, I plan to use JavaGroups for the
task (LGPL license), as well as some code which was donated a while ago
by Filip Hanik. Based on what is already done, the amount of work that 
will have to be done to have quality clustering features seems small.

Most of the current clustering API will be removed in the process, since
it doesn't seem to be maintained anymore, and didn't evolve past
experimental stage (if I am wrong on that, let me know).

I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB
standalone JAR. Configuring Tomcat for clustering will be quite easy
once all the code is in place.

I don't know if that plan is acceptable for everyone. Originally,
I -1ed the code submission because of licensing and absence of
integration with the existing Cluster API. The licensing issue is still 
there, but since the Cluster API now seems sort of dead, another 
solution has to be found (IMO, of course there's JK available).

Comments ?

I could be a full +1, if we could convince them to make JavaGroups 
BSD/Apache licence.

Or use something related with BSD license (see mod_backend)

Regards




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [5.0] Cluster features

[Shapira, Yoav]

Hi,
In a rush on my way to (yet another ;() meeting, so:

- The current cluster API is dead.
- JavaGroups is good.
- Clustering is important.
=> Your approach seems reasonable, +1 IMHO.

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, December 03, 2002 11:50 AM
>To: Tomcat Developers List
>Subject: [5.0] Cluster features
>
>Hi,
>
>I think the clustering features in Tomcat 5 should get an overhaul.
>Despite some licensing dicrepancies, I plan to use JavaGroups for the
>task (LGPL license), as well as some code which was donated a while ago
>by Filip Hanik. Based on what is already done, the amount of work that
>will have to be done to have quality clustering features seems small.
>
>Most of the current clustering API will be removed in the process,
since
>it doesn't seem to be maintained anymore, and didn't evolve past
>experimental stage (if I am wrong on that, let me know).
>
>I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB
>standalone JAR. Configuring Tomcat for clustering will be quite easy
>once all the code is in place.
>
>I don't know if that plan is acceptable for everyone. Originally,
>I -1ed the code submission because of licensing and absence of
>integration with the existing Cluster API. The licensing issue is still
>there, but since the Cluster API now seems sort of dead, another
>solution has to be found (IMO, of course there's JK available).
>
>Comments ?
>
>Remy
>
>
>--
>To unsubscribe, e-mail:   [EMAIL PROTECTED]>
>For additional commands, e-mail: [EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Remy Maucherat]

Henri Gomez wrote:

Remy Maucherat wrote:


Hi,

I think the clustering features in Tomcat 5 should get an overhaul.
Despite some licensing dicrepancies, I plan to use JavaGroups for the
task (LGPL license), as well as some code which was donated a while ago
by Filip Hanik. Based on what is already done, the amount of work that 
will have to be done to have quality clustering features seems small.

Most of the current clustering API will be removed in the process, since
it doesn't seem to be maintained anymore, and didn't evolve past
experimental stage (if I am wrong on that, let me know).

I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB
standalone JAR. Configuring Tomcat for clustering will be quite easy
once all the code is in place.

I don't know if that plan is acceptable for everyone. Originally,
I -1ed the code submission because of licensing and absence of
integration with the existing Cluster API. The licensing issue is 
still there, but since the Cluster API now seems sort of dead, another 
solution has to be found (IMO, of course there's JK available).

Comments ?


I could be a full +1, if we could convince them to make JavaGroups 
BSD/Apache licence.

Or donate it ;-)
One other project I have been working with (Slide) could definitely use 
a distributed cache.

Or use something related with BSD license (see mod_backend)


I forgot to mention it, but one missing piece of the puzzle is the HTTP 
proxy(ies) sitting in front of the cluster.

It could be:
- Some webserver + JK
- Apache 2 + mod_proxy
- some yet-to-be-written NIO based proxy (which probably wouldn't need 
to know anything about HTTP; doing a dumb TCP proxy might be enough)

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Costin Manolache]

Remy Maucherat wrote:

> Hi,
> 
> I think the clustering features in Tomcat 5 should get an overhaul.
> Despite some licensing dicrepancies, I plan to use JavaGroups for the
> task (LGPL license), as well as some code which was donated a while ago
> by Filip Hanik. Based on what is already done, the amount of work that
> will have to be done to have quality clustering features seems small.
> 
> Most of the current clustering API will be removed in the process, since
> it doesn't seem to be maintained anymore, and didn't evolve past
> experimental stage (if I am wrong on that, let me know).
> 
> I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB
> standalone JAR. Configuring Tomcat for clustering will be quite easy
> once all the code is in place.
> 
> I don't know if that plan is acceptable for everyone. Originally,
> I -1ed the code submission because of licensing and absence of
> integration with the existing Cluster API. The licensing issue is still
> there, but since the Cluster API now seems sort of dead, another
> solution has to be found (IMO, of course there's JK available).
> 
> Comments ?

+1 if all new code goes in a separate module ( instead of catalina ), 
and is built as separate .jar(s).

I think it is time to stop bloating the base tomcat source and binaries.

BTW, it may be a good time to move some of the current features in separate
modules as well. ( SSI, WebDAV, etc ). For webdav - I would rather see slide
bundled with tomcat and the current code deprecated.

I'm not talking ( for now ) about a real module with descriptors or 
anything, just separate dirs in the CVS and a .jar target that can be 
included or not. 

It may be worth reopening the "minimal tomcat" discussion :-)

Costin
 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Remy Maucherat]

Costin Manolache wrote:

Remy Maucherat wrote:



Hi,

I think the clustering features in Tomcat 5 should get an overhaul.
Despite some licensing dicrepancies, I plan to use JavaGroups for the
task (LGPL license), as well as some code which was donated a while ago
by Filip Hanik. Based on what is already done, the amount of work that
will have to be done to have quality clustering features seems small.

Most of the current clustering API will be removed in the process, since
it doesn't seem to be maintained anymore, and didn't evolve past
experimental stage (if I am wrong on that, let me know).

I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB
standalone JAR. Configuring Tomcat for clustering will be quite easy
once all the code is in place.

I don't know if that plan is acceptable for everyone. Originally,
I -1ed the code submission because of licensing and absence of
integration with the existing Cluster API. The licensing issue is still
there, but since the Cluster API now seems sort of dead, another
solution has to be found (IMO, of course there's JK available).

Comments ?



+1 if all new code goes in a separate module ( instead of catalina ), 
and is built as separate .jar(s).

I wanted to, however I can't do that without changing the API some stuff 
in the session package (the damn classes are all package private) :-P

I suppose it's a lot better to stop the hacks *now*, fix that, and put 
everything in the cluster package.

I think it is time to stop bloating the base tomcat source and binaries.

BTW, it may be a good time to move some of the current features in separate
modules as well. ( SSI, WebDAV, etc ). For webdav - I would rather see slide
bundled with tomcat and the current code deprecated.

I'm not talking ( for now ) about a real module with descriptors or 
anything, just separate dirs in the CVS and a .jar target that can be 
included or not. 

Ok.


It may be worth reopening the "minimal tomcat" discussion :-)


Maybe. If the difference is only a couple MBs, then it's not worth it, 
though.

If we do an alternate distribution, it would have to be radically 
different IMO (like for example, being a simple set of JARs without the 
complex dir structure). The laucher + the catalina.properties + future 
mods to the config system should make that easy.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Costin Manolache]

Remy Maucherat wrote:


>> +1 if all new code goes in a separate module ( instead of catalina ),
>> and is built as separate .jar(s).
> 
> I wanted to, however I can't do that without changing the API some stuff
> in the session package (the damn classes are all package private) :-P
> 
> I suppose it's a lot better to stop the hacks *now*, fix that, and put
> everything in the cluster package.

Well, if you must - you must. 
But we shouldn't have the core depend on the clustering, just add the 
minimal stuff that you need in the session. 

If we can stop the hacks and clean something - I think 5.0 is the best 
chance.

I would preffer to have a consistent hook mechanism for everything - 
I'm not sure what callbacks will be involved in the clustering.
 

>> It may be worth reopening the "minimal tomcat" discussion :-)
> 
> Maybe. If the difference is only a couple MBs, then it's not worth it,
> though.

Bloat is not about MB or storage. It's about code complexity, potential
security, etc. 


> If we do an alternate distribution, it would have to be radically
> different IMO (like for example, being a simple set of JARs without the
> complex dir structure). The laucher + the catalina.properties + future
> mods to the config system should make that easy.

That's what I was thinking about - a set of jars and minimal configuration.
Eventually using only MBeans for configuration and setup.

BTW, we could use MBeans for the optional packages too. I think it works
pretty well. We'll need to get a consensus on requiring JMX for tomcat5,
but so far it doesn't seem it'll have a big impact on the code ( I did
all kind of experiments with modeler and ant lately ).

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Remy Maucherat]

Costin Manolache wrote:

Remy Maucherat wrote:




+1 if all new code goes in a separate module ( instead of catalina ),
and is built as separate .jar(s).


I wanted to, however I can't do that without changing the API some stuff
in the session package (the damn classes are all package private) :-P

I suppose it's a lot better to stop the hacks *now*, fix that, and put
everything in the cluster package.



Well, if you must - you must. 
But we shouldn't have the core depend on the clustering, just add the 
minimal stuff that you need in the session. 

If we can stop the hacks and clean something - I think 5.0 is the best 
chance.

I would preffer to have a consistent hook mechanism for everything - 
I'm not sure what callbacks will be involved in the clustering.

I'll remove stuff in the Cluster API, modify some of the session classes 
to allow extending them in a different package, and everything in the 
core is then independent of the clustering.

It may be worth reopening the "minimal tomcat" discussion :-)


Maybe. If the difference is only a couple MBs, then it's not worth it,
though.



Bloat is not about MB or storage. It's about code complexity, potential
security, etc. 

Ok. All distributions need to be thought as secure, though.


If we do an alternate distribution, it would have to be radically
different IMO (like for example, being a simple set of JARs without the
complex dir structure). The laucher + the catalina.properties + future
mods to the config system should make that easy.



That's what I was thinking about - a set of jars and minimal configuration.
Eventually using only MBeans for configuration and setup.


I thought this was supposed to be JNDI. JMX does not have any support 
for bean state serialization, right ?

BTW, we could use MBeans for the optional packages too. I think it works
pretty well. We'll need to get a consensus on requiring JMX for tomcat5,
but so far it doesn't seem it'll have a big impact on the code ( I did
all kind of experiments with modeler and ant lately ).


+1 for JMX (as there's MX4J); as well as JNDI, BTW.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Jeanfrancois Arcand]

Costin Manolache wrote:


Remy Maucherat wrote:


 

+1 if all new code goes in a separate module ( instead of catalina ),
and is built as separate .jar(s).
 

I wanted to, however I can't do that without changing the API some stuff
in the session package (the damn classes are all package private) :-P

I suppose it's a lot better to stop the hacks *now*, fix that, and put
everything in the cluster package.
   


Well, if you must - you must. 
But we shouldn't have the core depend on the clustering, just add the 
minimal stuff that you need in the session. 

If we can stop the hacks and clean something - I think 5.0 is the best 
chance.

I would preffer to have a consistent hook mechanism for everything - 
I'm not sure what callbacks will be involved in the clustering.

Are you thinking about having coyote Action(s)?  If yes, we might one to 
extend the current API having in mind that we will need to supports 
Clustering, Authentification, Authorization, etc. 



 

It may be worth reopening the "minimal tomcat" discussion :-)
 

Maybe. If the difference is only a couple MBs, then it's not worth it,
though.
   


Bloat is not about MB or storage. It's about code complexity, potential
security, etc. 


 

If we do an alternate distribution, it would have to be radically
different IMO (like for example, being a simple set of JARs without the
complex dir structure). The laucher + the catalina.properties + future
mods to the config system should make that easy.
   


That's what I was thinking about - a set of jars and minimal configuration.
Eventually using only MBeans for configuration and setup.

BTW, we could use MBeans for the optional packages too. I think it works
pretty well. We'll need to get a consensus on requiring JMX for tomcat5,
but so far it doesn't seem it'll have a big impact on the code ( I did
all kind of experiments with modeler and ant lately ).

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 

Re: [5.0] Cluster features

[Jeanfrancois Arcand]

Remy Maucherat wrote:


Costin Manolache wrote:


Remy Maucherat wrote:




+1 if all new code goes in a separate module ( instead of catalina ),
and is built as separate .jar(s).



I wanted to, however I can't do that without changing the API some 
stuff
in the session package (the damn classes are all package private) :-P

I suppose it's a lot better to stop the hacks *now*, fix that, and put
everything in the cluster package.



Well, if you must - you must. But we shouldn't have the core depend 
on the clustering, just add the minimal stuff that you need in the 
session.
If we can stop the hacks and clean something - I think 5.0 is the 
best chance.

I would preffer to have a consistent hook mechanism for everything - 
I'm not sure what callbacks will be involved in the clustering.


I'll remove stuff in the Cluster API, modify some of the session 
classes to allow extending them in a different package, and everything 
in the core is then independent of the clustering. 

No security problems if we kept the current package protection 
mechanism. Making those classes "public" can be dangerous if the package 
protection is not enabled.




It may be worth reopening the "minimal tomcat" discussion :-)



Maybe. If the difference is only a couple MBs, then it's not worth it,
though.




Bloat is not about MB or storage. It's about code complexity, potential
security, etc. 


Ok. All distributions need to be thought as secure, though. 

Does that implies re-writting the current set of classloader? It might 
be a good time to revisit classloader and security :-)




If we do an alternate distribution, it would have to be radically
different IMO (like for example, being a simple set of JARs without the
complex dir structure). The laucher + the catalina.properties + future
mods to the config system should make that easy.




That's what I was thinking about - a set of jars and minimal 
configuration.
Eventually using only MBeans for configuration and setup.


I thought this was supposed to be JNDI. JMX does not have any support 
for bean state serialization, right ?

BTW, we could use MBeans for the optional packages too. I think it works
pretty well. We'll need to get a consensus on requiring JMX for tomcat5,
but so far it doesn't seem it'll have a big impact on the code ( I did
all kind of experiments with modeler and ant lately ).



+1 for JMX (as there's MX4J); as well as JNDI, BTW. 

+1

-- Jeanfrancois




Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Costin Manolache]

Jeanfrancois Arcand wrote:

+1 if all new code goes in a separate module ( instead of catalina ),
and is built as separate .jar(s).
  

>>>I wanted to, however I can't do that without changing the API some stuff
>>>in the session package (the damn classes are all package private) :-P
>>>
>>>I suppose it's a lot better to stop the hacks *now*, fix that, and put
>>>everything in the cluster package.
>>>
>>>
>>
>>Well, if you must - you must.
>>But we shouldn't have the core depend on the clustering, just add the
>>minimal stuff that you need in the session.
>>
>>If we can stop the hacks and clean something - I think 5.0 is the best
>>chance.
>>
>>I would preffer to have a consistent hook mechanism for everything -
>>I'm not sure what callbacks will be involved in the clustering.
>>
> Are you thinking about having coyote Action(s)?  If yes, we might one to
> extend the current API having in mind that we will need to supports
> Clustering, Authentification, Authorization, etc.

I don't care too much if it is called Coyote Action, Jk2 Handler, 
3.3 Interceptor(with a single method), or 4.0 Valve ( in multiple chains )
or Axis Handler/Chain. Or even Event/Listener.

Some time ago I started a package to implement yet-another hook, as a 
replacement for Action in coyote. I remove it because there is absolutely
no point for yet another API - any of those APIs can do the job.

All I want is a single and simple and consistent hook mechanism that is used 
for callbacks in all "extension points" ( simple is quite important :-)

Since Coyote is now used in all tomcat versions and also jk - I think
it is a good idea to use with coyote Action. But I'm +1 on anything else -
as long as we converge on a single mechanism ( it is simple
to wrap any hook - Vavle, interceptor, action. into any interface )


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Costin Manolache]

Jeanfrancois Arcand wrote:


>> I'll remove stuff in the Cluster API, modify some of the session
>> classes to allow extending them in a different package, and everything
>> in the core is then independent of the clustering.
> 
> No security problems if we kept the current package protection
> mechanism. Making those classes "public" can be dangerous if the package
> protection is not enabled.

That depends on the class loader - if tomcat is embedded in something else
( like J2EE or some other app ) I'm not sure how it'll protect this.

Also, a number of classes are public because they are intended to be used, 
and a number of security problems may happen ( as we learned ) even if the
class is not accessible ( like the recent web.xml entity issues ).


>>> Bloat is not about MB or storage. It's about code complexity, potential
>>> security, etc.
>>
>>
>> Ok. All distributions need to be thought as secure, though.
> 
> Does that implies re-writting the current set of classloader? It might
> be a good time to revisit classloader and security :-)

Do you have so much free time :-) ? I'm +1 BTW.

If we reach consensus on JMX - it may be a good idea to use its class 
loading mechanism, or something very close - the model in theory is 
very good. You have full control ( using mlet tags or API ) over
the class loaders and hierarchy.

>> +1 for JMX (as there's MX4J); as well as JNDI, BTW.
> 
> +1

I'll send a separate mail with a VOTE subject.

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Jeanfrancois Arcand]

Costin Manolache wrote:


Jeanfrancois Arcand wrote:


 

I'll remove stuff in the Cluster API, modify some of the session
classes to allow extending them in a different package, and everything
in the core is then independent of the clustering.
 

No security problems if we kept the current package protection
mechanism. Making those classes "public" can be dangerous if the package
protection is not enabled.
   


That depends on the class loader - if tomcat is embedded in something else
( like J2EE or some other app ) I'm not sure how it'll protect this.


It will work if, in their classloader implementation, they call 
securityManager.checkPackageDefinition(...). The current J2EE 1.4 RI 
doesn't., and most of the EE implementation doesn't because of the 
Security Manager performance hit.


Also, a number of classes are public because they are intended to be used, 
and a number of security problems may happen ( as we learned ) even if the
class is not accessible ( like the recent web.xml entity issues ).


 

Bloat is not about MB or storage. It's about code complexity, potential
security, etc.
   

Ok. All distributions need to be thought as secure, though.
 

Does that implies re-writting the current set of classloader? It might
be a good time to revisit classloader and security :-)
   


Do you have so much free time :-) ? I'm +1 BTW.


What do you do when its -20 celcius? ;-) Try to find something to "warm" 
yourself :-)  

I was under the impression Remy was having a proposal for the 
classloader stuff. (IMBW). Once I have a clear understanding on all the 
hooks (inclusing Axis/Apache), I would certainly work on his proposal :-)

-- Jeanfrancois


If we reach consensus on JMX - it may be a good idea to use its class 
loading mechanism, or something very close - the model in theory is 
very good. You have full control ( using mlet tags or API ) over
the class loaders and hierarchy.

 

+1 for JMX (as there's MX4J); as well as JNDI, BTW.
 

+1
   


I'll send a separate mail with a VOTE subject.

Costin
 






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 

RE: [5.0] Cluster features

[Filip Hanik]

we have a project on sourceforge to continue development of this.
but we would love to integrate this into Tomcat where it really belongs.
http://sourceforge.net/projects/tomcat-jg
Filip

~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
www.filip.net

>-Original Message-
>From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, December 03, 2002 8:50 AM
>To: Tomcat Developers List
>Subject: [5.0] Cluster features
>
>
>Hi,
>
>I think the clustering features in Tomcat 5 should get an overhaul.
>Despite some licensing dicrepancies, I plan to use JavaGroups for the
>task (LGPL license), as well as some code which was donated a while ago
>by Filip Hanik. Based on what is already done, the amount of work that
>will have to be done to have quality clustering features seems small.
>
>Most of the current clustering API will be removed in the process, since
>it doesn't seem to be maintained anymore, and didn't evolve past
>experimental stage (if I am wrong on that, let me know).
>
>I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB
>standalone JAR. Configuring Tomcat for clustering will be quite easy
>once all the code is in place.
>
>I don't know if that plan is acceptable for everyone. Originally,
>I -1ed the code submission because of licensing and absence of
>integration with the existing Cluster API. The licensing issue is still
>there, but since the Cluster API now seems sort of dead, another
>solution has to be found (IMO, of course there's JK available).
>
>Comments ?
>
>Remy
>
>
>--
>To unsubscribe, e-mail:

For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Henri Gomez]

Filip Hanik wrote:

we have a project on sourceforge to continue development of this.
but we would love to integrate this into Tomcat where it really belongs.
http://sourceforge.net/projects/tomcat-jg


It seems JavaGroup could be a great candidate as jakarta project,
you even got the right look :)

http://www.javagroups.com/javagroupsnew/docs/index.html

What about changing licence to BSD/Apache and ask for being
a jakarta project ?

You'll have my full +1 (and of many tomcat developpers).

Gain :

- You'll could put your tomcat jg works back in TC 4.x

- You'll provide a great API to jakarta where many projects
  could have the need of.

And of course you'll find many new friends here in ASF ...






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Glenn Nielsen]

Costin Manolache wrote:

Remy Maucherat wrote:



Hi,

I think the clustering features in Tomcat 5 should get an overhaul.
Despite some licensing dicrepancies, I plan to use JavaGroups for the
task (LGPL license), as well as some code which was donated a while ago
by Filip Hanik. Based on what is already done, the amount of work that
will have to be done to have quality clustering features seems small.

Most of the current clustering API will be removed in the process, since
it doesn't seem to be maintained anymore, and didn't evolve past
experimental stage (if I am wrong on that, let me know).

I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB
standalone JAR. Configuring Tomcat for clustering will be quite easy
once all the code is in place.

I don't know if that plan is acceptable for everyone. Originally,
I -1ed the code submission because of licensing and absence of
integration with the existing Cluster API. The licensing issue is still
there, but since the Cluster API now seems sort of dead, another
solution has to be found (IMO, of course there's JK available).

Comments ?



+1 if all new code goes in a separate module ( instead of catalina ), 
and is built as separate .jar(s).

I think it is time to stop bloating the base tomcat source and binaries.

BTW, it may be a good time to move some of the current features in separate
modules as well. ( SSI, WebDAV, etc ). For webdav - I would rather see slide
bundled with tomcat and the current code deprecated.

I'm not talking ( for now ) about a real module with descriptors or 
anything, just separate dirs in the CVS and a .jar target that can be 
included or not. 

It may be worth reopening the "minimal tomcat" discussion :-)

Costin
 

+1 to Costin's comments




--
To unsubscribe, e-mail:   
For additional commands, e-mail: