jmailsrv-development Mailing List for Java Mail Server
Status: Beta
Brought to you by:
furykid
Menu
▾
▴
jmailsrv-development — for development related topics
You can subscribe to this list here.
| 2002 |
Jan
(35) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Benno L. <ben...@id...> - 2004-05-03 07:17:24
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_de.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Hedzer v. D. <he...@yl...> - 2004-01-10 11:53:13
|
Hi again, Never mind the last question, I already noticed that the Pop3 classes are just meant for 'local' work, not for the remote POP3 servers. Regards, Hedzer Hedzer van Dijk wrote: > Hi all, > > I started using jmailsrv yesterday with two remote pop3 mailservers. > I was able to collect the mail from one of them but the other would > consequently hang. After some debugging I noticed that it hang after > sending the USER command. When I checked the POP3 rfc, it said that > all commands should end with CR/LF. The code however sends the command > using println and on Linux this will send a LF (or CR, I can never > remember which one) after the command. Not all POP3 mailservers seem > to be this picky, since my other one accepts just the LF. > > The sollution would be to use the print method and append a '\r\n' > after every command (I tested this in a few lines of code and it > works). The println method is used in Sender, SmptConnection, > Pop3Connection and Fetcher and all in all it will take quite a few > changes. I will probably change all the code that I need to, to get it > working here, but I don't feel comfortable changing the 'production' > code. > > One other question: why are the Pop3Server and Pop3Connection classes > not used by Fetcher? > > Regards, Hedzer > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Jmailsrv-development mailing list > Jma...@li... > https://lists.sourceforge.net/lists/listinfo/jmailsrv-development > |
|
From: Hedzer v. D. <he...@yl...> - 2004-01-10 11:48:13
|
Hi all, I started using jmailsrv yesterday with two remote pop3 mailservers. I was able to collect the mail from one of them but the other would consequently hang. After some debugging I noticed that it hang after sending the USER command. When I checked the POP3 rfc, it said that all commands should end with CR/LF. The code however sends the command using println and on Linux this will send a LF (or CR, I can never remember which one) after the command. Not all POP3 mailservers seem to be this picky, since my other one accepts just the LF. The sollution would be to use the print method and append a '\r\n' after every command (I tested this in a few lines of code and it works). The println method is used in Sender, SmptConnection, Pop3Connection and Fetcher and all in all it will take quite a few changes. I will probably change all the code that I need to, to get it working here, but I don't feel comfortable changing the 'production' code. One other question: why are the Pop3Server and Pop3Connection classes not used by Fetcher? Regards, Hedzer |
|
From: Chris D. <c.d...@cd...> - 2002-03-13 01:54:27
|
Hi, CVS tells me it has been 6 weeks since I submitted my classes, and still I haven't done any useful integration of them *shame* :( I hope other people aren't waiting on me finishing my part of the project. How are things going on the other aspects of the Web interface? Thanks, C.Davies. |
|
From: Furykid <fu...@us...> - 2002-02-10 10:16:45
|
Hi, looks good how did you plan to proceed ? is there already a new rmi interface available ? best regards johannes -----Original Message----- From: jma...@li... [mailto:jma...@li...] On Behalf Of Eugene Vogel Sent: Montag, 21. J=E4nner 2002 01:34 To: Jma...@li... Subject: Re[2]: [Jmailsrv-development] Web tier architecture Hello Ben, I've uploaded adopted version of design to www.mycgiserver.com/~evogel/jms.zip . It is whole JBuilder project subdirectory with sources, jsp-s and classes.Inspect it, it's nearly working version. What is remaining is wrote in adminwriter.java (also see comments for understanding). If you do not understand something, ask me, I'll be happy to answer. About sharing work: I offer you to write reading and parsing of incoming object, it is method readData() in adminwriter. Writing writeData() will not bad, too ;-) Waiting for your reply.. Best regards, Eugene mailto:gh...@ma... _______________________________________________ Jmailsrv-development mailing list Jma...@li... https://lists.sourceforge.net/lists/listinfo/jmailsrv-development |
|
From: Eugene V. <gh...@ma...> - 2002-01-21 00:34:24
|
Hello Ben, I've uploaded adopted version of design to www.mycgiserver.com/~evogel/jms.zip . It is whole JBuilder project subdirectory with sources, jsp-s and classes.Inspect it, it's nearly working version. What is remaining is wrote in adminwriter.java (also see comments for understanding). If you do not understand something, ask me, I'll be happy to answer. About sharing work: I offer you to write reading and parsing of incoming object, it is method readData() in adminwriter. Writing writeData() will not bad, too ;-) Waiting for your reply.. Best regards, Eugene mailto:gh...@ma... |
|
From: Furykid <fu...@us...> - 2002-01-20 12:33:27
|
Hi,
generally I would prefer that only value objects are passed between mail
server and web tier.
after login a user object is stored with session scope ( which will be
used later for=20
the client part as well).
after login ( and verification that the current user has admin rights)
the
configuration part is visible.=20
Parsing the config file ( should only be done in the mail server) to
avoid duplicating this
code which might change due to another form of saving the properties.
I would use the existing pages of the config tools as stating point for
identifying the
needed beans.
the pages with simple fields could be constructed by a single jsp using
reflection, but this
is just a suggestion ( for each property of the bean a corresponding
label info & description could
be defined).
for the user administration section we have to specify how we generally
pass the information
between tiers ( as this might become a lot of data, and should not be
passed at once).
regards
johannes
-----Original Message-----
From: jma...@li...
[mailto:jma...@li...] On Behalf Of
Eugene Vogel
Sent: Samstag, 19. J=E4nner 2002 20:23
To: Jma...@li...
Subject: Re: [Jmailsrv-development] Web tier architecture
Hello Ben,
Ok, if discussion is over, will someone clarify that question with
passing info ? Finally, what will we pass: xml file or object ?
BC> continuing to write RMI code, then Eugene, let's identify how many=20
BC> JSP's
BC> we need, what each does, and who should do it (assuming nobody has
yet).
Ok, I'll write about how I see our jsps and beans.It's just one possible
variant, may be we should think about control servlet system, where all
links points to one servlet, where all work takes place...
login.jsp -> autorization.jsp (uses validating bean, this bean will
perform actual check) -> forwarding (assume that user is admin) -> main
page (ie servers.jsp).
Now more difficult part begins, when validatebean confirms that
login/pass is ok, it creates new bean (ie admin.class) that retrieves
by RMI object/xml file. This file will be saved locally as temp file.
Then when forwarding to main page takes place, following will happens :
temp file will be parsed for sections and will be created main html
file with links to pages, that corresponds to sections, that were found
in file. Next, let's see on how page processing will go. Take for
example servers.jsp. Servers.jsp consist of server's header and calls
tag library method from admin.class with parameter data=3D"servers", =
that
parses temp file and looks for options from section "servers". Then
this class generates page with servers options. Form's "action"
parameter will always point to one file: process.jsp, where changed
parameters will be saved to temp file by admin.class. Then when forward
is going to servers.jsp again from process.jsp, admin.class parses
again temp file and changed options can be seen already. The same
things will be on each page. So when user clicks on link "Commit", temp
file is sent back to server. When user logs out, temp file will be
deleted.
Here are some drafts for you to demonstrate, how work will be
done:
autorization.jsp /*
<%@ page contentType=3D"text/html; charset=3Dwindows-1251" %> =
<jsp:useBean
id=3D"InitBeanId" scope=3D"session" class=3D"jms.InitBean" /> =
<jsp:setProperty
name=3D"InitBeanId" property=3D"*" /> <% InitBeanId.validate(); %> <% if
(InitBeanId.isValid()) {%> <jsp:useBean id=3D"userId" scope=3D"session"
class=3D"jms.user" /> <jsp:setProperty name=3D"userId" property=3D"name"
value=3D"<%=3D InitBeanId.getName()%>"/> <jsp:setProperty =
name=3D"userId"
property=3D"rights" value=3D"<%=3D InitBeanId.getRights()%>" /> =
<jsp:forward
page=3D"main.jsp" /> <% } else { %> <jsp:setProperty name=3D"InitBeanId"
property=3D"message" value=3D"You entered wrong information"/> =
<jsp:forward
page=3D"Init.jsp" /> <% } %>
*/
servers.jsp /*
<%@ page contentType=3D"text/html; charset=3Dwindows-1251" %>
<%@ taglib uri=3D"/WEB-INF/jms.tld" prefix=3D"jmswriter" %> <jsp:useBean
id=3D"userId" scope=3D"session" class=3D"jms.user" /> <% if
(userId.getName().equals("")) { %> <jsp:forward page=3D"Init.jsp" >
<jsp:param name=3D"message" value=3D"Please log in first" />
</jsp:forward> <% } %> <jsp:useBean id=3D"aw" scope=3D"session"
class=3D"jms.AdminWriter" /> <jsp:setProperty name=3D"aw" =
property=3D"*"/>
<jsp:setProperty name=3D"userId" property=3D"configpage" =
value=3D"servers"/>
<html> <head> <title>General Settings</title> <meta
http-equiv=3D'Content-Type' content=3D'text/html; charset=3Diso-8859-1'>
</head>
<body bgcolor=3D'#CCCCCC' text=3D'#000000'>
<table width=3D'661' border=3D'0' cellpadding=3D'0' cellspacing=3D'0'
mm:layoutgroup=3D'true' height=3D'277'>
<tr>
<td width=3D'1' height=3D'6'></td>
<td width=3D'660'></td>
<td width=3D'1'></td>
</tr>
<tr>
<td width=3D'1' height=3D'270'></td>
<td valign=3D'top' width=3D'660' height=3D'270'>
<jmswriter:base operation=3D"read" data=3D"servers" /> // HERE =
FULFILLMENT
WITH DATA TAKES PLACE
</td>
<td width=3D'1' height=3D'270'></td>
</tr>
</table>
</body>
</html>
*/
process.jsp /* HERE SOME CHANGES SHOULD BE PERFORMED, THIS VERSION IS
FOR STATIC PAGES, NOT FOR DYNAMIC ONES. BUT PRINCIPLE IS THE SAME.
<%@ page contentType=3D"text/html; charset=3Dwindows-1251" %> =
<jsp:useBean
id=3D"userId" scope=3D"session" class=3D"jms.user" /> <% if
(userId.getName().equals("")) { %> <jsp:forward page=3D"Init.jsp" >
<jsp:param name=3D"message" value=3D"Please log in first" />
</jsp:forward> <% } %> <jsp:useBean id=3D"aw" scope=3D"session"
class=3D"jms.AdminWriter" />
<jsp:setProperty name=3D"aw" property=3D"*"/> /* HERE PARAMETERS
FROM PREVIOUS PAGE ARE PASSED. */
<%
String where =3D "";
if (userId.getConfigpage().equals("logs")) {
where =3D "logs.jsp";
}
if (userId.getConfigpage().equals("jdbcs")) {
where =3D "jdbcs.jsp";
String[] pickedq =3D request.getParameterValues("enablejdbc");
if (pickedq !=3D null && pickedq.length !=3D 0) {
aw.setEnablejdbc("checked");
} else {
aw.setEnablejdbc("");
}
}
if (userId.getConfigpage().equals("servers")) {
where =3D "servers.jsp";
String[] picked1 =3D request.getParameterValues("fetcherrundaemon");
if (picked1 !=3D null && picked1.length !=3D 0) {
aw.setFetcherrundaemon("checked");
} else {
aw.setFetcherrundaemon("");
}
String[] picked2 =3D request.getParameterValues("senderrundaemon");
if (picked2 !=3D null && picked2.length !=3D 0) {
aw.setSenderrundaemon("checked");
} else {
aw.setSenderrundaemon("");
}
String[] picked3 =3D request.getParameterValues("showstatuswindow");
if (picked3 !=3D null && picked3.length !=3D 0) {
aw.setShowstatuswindow("checked");
} else {
aw.setShowstatuswindow("");
}
String[] picked4 =3D request.getParameterValues("bigbrother");
if (picked4 !=3D null && picked4.length !=3D 0) {
aw.setBigbrother("checked");
} else {
aw.setBigbrother("");
}
}
%>
<% aw.writeit(userId.getConfigpage()); %>
<jsp:forward page=3D"<%=3D where%>" />
*/
If you think, that it is overcomplicated, reply, I'm opened for any
ideas. May be we can try to simplify pages or create them different way.
Feature of this model is that all works actually is in one file -
admin.class.
=20
EV>> If there will be new options, what will you do with your xslt file
BC> ? Create new version each time ?
BC> Yes, someone would absolutely have to make a new XSLT if the config=20
BC> XML
BC> file changed. However, the servlet may not even need recompiling if
we=20
BC> were smart about it. Were you insinuating that with a JSP model, we
BC> wouldn't have to rewrite under the same circumstances?
With JSP model, that I've wrote above we do not "populate", we generate
from scratch each time, depending on our info file so there is no need
in updating client if there are new options.
Best regards, Eugene mailto:gh...@ma...
_______________________________________________
Jmailsrv-development mailing list
Jma...@li...
https://lists.sourceforge.net/lists/listinfo/jmailsrv-development
|
|
From: Eugene V. <gh...@ma...> - 2002-01-19 19:23:05
|
Hello Ben,
Ok, if discussion is over, will someone clarify that question with passing info ?
Finally, what will we pass: xml file or object ?
BC> continuing to write RMI code, then Eugene, let's identify how many JSP's
BC> we need, what each does, and who should do it (assuming nobody has yet).
Ok, I'll write about how I see our jsps and beans.It's just one
possible variant, may be we should think about control servlet system,
where all links points to one servlet, where all work takes place...
login.jsp -> autorization.jsp (uses validating bean, this bean will
perform actual check) -> forwarding (assume that user is admin) ->
main page (ie servers.jsp).
Now more difficult part begins, when validatebean confirms that
login/pass is ok, it creates new bean (ie admin.class) that retrieves
by RMI object/xml file. This file will be saved locally as temp file.
Then when forwarding to main page takes place,
following will happens : temp file will be parsed for sections and
will be created main html file with links to pages, that corresponds to
sections, that were found in file. Next, let's see on how page
processing will go. Take for example servers.jsp.
Servers.jsp consist of server's header and calls tag
library method from admin.class with parameter data="servers", that
parses temp file and looks for options from section "servers". Then
this class generates page with servers options. Form's "action" parameter
will always point to one file: process.jsp, where changed parameters
will be saved to temp file by admin.class. Then when forward is going
to servers.jsp again from process.jsp, admin.class parses again temp
file and changed options can be seen already. The same things will be
on each page. So when user clicks on link "Commit", temp file is sent
back to server. When user logs out, temp file will be deleted.
Here are some drafts for you to demonstrate, how work will be
done:
autorization.jsp /*
<%@ page contentType="text/html; charset=windows-1251" %>
<jsp:useBean id="InitBeanId" scope="session" class="jms.InitBean" />
<jsp:setProperty name="InitBeanId" property="*" />
<% InitBeanId.validate(); %>
<% if (InitBeanId.isValid()) {%>
<jsp:useBean id="userId" scope="session" class="jms.user" />
<jsp:setProperty name="userId" property="name" value="<%= InitBeanId.getName()%>"/>
<jsp:setProperty name="userId" property="rights" value="<%= InitBeanId.getRights()%>" />
<jsp:forward page="main.jsp" />
<% } else { %>
<jsp:setProperty name="InitBeanId" property="message" value="You entered wrong information"/>
<jsp:forward page="Init.jsp" />
<% } %>
*/
servers.jsp /*
<%@ page contentType="text/html; charset=windows-1251" %>
<%@ taglib uri="/WEB-INF/jms.tld" prefix="jmswriter" %>
<jsp:useBean id="userId" scope="session" class="jms.user" />
<% if (userId.getName().equals("")) { %>
<jsp:forward page="Init.jsp" >
<jsp:param name="message" value="Please log in first" />
</jsp:forward>
<% } %>
<jsp:useBean id="aw" scope="session" class="jms.AdminWriter" />
<jsp:setProperty name="aw" property="*"/>
<jsp:setProperty name="userId" property="configpage" value="servers"/>
<html>
<head>
<title>General Settings</title>
<meta http-equiv='Content-Type' content='text/html; charset=iso-8859-1'>
</head>
<body bgcolor='#CCCCCC' text='#000000'>
<table width='661' border='0' cellpadding='0' cellspacing='0' mm:layoutgroup='true' height='277'>
<tr>
<td width='1' height='6'></td>
<td width='660'></td>
<td width='1'></td>
</tr>
<tr>
<td width='1' height='270'></td>
<td valign='top' width='660' height='270'>
<jmswriter:base operation="read" data="servers" /> // HERE FULFILLMENT
WITH DATA TAKES PLACE
</td>
<td width='1' height='270'></td>
</tr>
</table>
</body>
</html>
*/
process.jsp /* HERE SOME CHANGES SHOULD BE PERFORMED, THIS VERSION IS
FOR STATIC PAGES, NOT FOR DYNAMIC ONES. BUT PRINCIPLE IS THE SAME.
<%@ page contentType="text/html; charset=windows-1251" %>
<jsp:useBean id="userId" scope="session" class="jms.user" />
<% if (userId.getName().equals("")) { %>
<jsp:forward page="Init.jsp" >
<jsp:param name="message" value="Please log in first" />
</jsp:forward>
<% } %>
<jsp:useBean id="aw" scope="session" class="jms.AdminWriter" />
<jsp:setProperty name="aw" property="*"/> /* HERE PARAMETERS
FROM PREVIOUS PAGE ARE PASSED. */
<%
String where = "";
if (userId.getConfigpage().equals("logs")) {
where = "logs.jsp";
}
if (userId.getConfigpage().equals("jdbcs")) {
where = "jdbcs.jsp";
String[] pickedq = request.getParameterValues("enablejdbc");
if (pickedq != null && pickedq.length != 0) {
aw.setEnablejdbc("checked");
} else {
aw.setEnablejdbc("");
}
}
if (userId.getConfigpage().equals("servers")) {
where = "servers.jsp";
String[] picked1 = request.getParameterValues("fetcherrundaemon");
if (picked1 != null && picked1.length != 0) {
aw.setFetcherrundaemon("checked");
} else {
aw.setFetcherrundaemon("");
}
String[] picked2 = request.getParameterValues("senderrundaemon");
if (picked2 != null && picked2.length != 0) {
aw.setSenderrundaemon("checked");
} else {
aw.setSenderrundaemon("");
}
String[] picked3 = request.getParameterValues("showstatuswindow");
if (picked3 != null && picked3.length != 0) {
aw.setShowstatuswindow("checked");
} else {
aw.setShowstatuswindow("");
}
String[] picked4 = request.getParameterValues("bigbrother");
if (picked4 != null && picked4.length != 0) {
aw.setBigbrother("checked");
} else {
aw.setBigbrother("");
}
}
%>
<% aw.writeit(userId.getConfigpage()); %>
<jsp:forward page="<%= where%>" />
*/
If you think, that it is overcomplicated, reply, I'm opened for any
ideas. May be we can try to simplify pages or create them different way.
Feature of this model is that all works actually is in one file - admin.class.
EV>> If there will be new options, what will you do with your xslt file
BC> ? Create new version each time ?
BC> Yes, someone would absolutely have to make a new XSLT if the config XML
BC> file changed. However, the servlet may not even need recompiling if we
BC> were smart about it. Were you insinuating that with a JSP model, we
BC> wouldn't have to rewrite under the same circumstances?
With JSP model, that I've wrote above we do not "populate", we generate from
scratch each time, depending on our info file so there is no need in updating
client if there are new options.
Best regards, Eugene mailto:gh...@ma...
|
|
From: Chris D. <c.d...@cd...> - 2002-01-18 23:03:20
|
Hi, OK great. I'll commit that to CVS some time over the weekend. I'll have to change some of the Batch files as well to make sure everything still works with the new security manager, but this should be no problem. I'll also add some features to ensure that clients connecting from 127.0.0.1 don't have to authenticate themselves, so that the GUI config tool still works fine. Thanks, C.Davies Furykid wrote: > Hi, > > Sorry chris I didnt find time to lok on your rmi reeimplementation but > if you think > it is necessary just go on ! > There would have been a problem with my implementation anway, because of > the user data > passed all at once. > for the new design please make it as extensible as possible for maybe > some option > will be added later. > > thanks again to you all for your support and have fun ! > > I am currently dealing with the IMAP protocoll integration, so the > basecode will not change > ( at least not from me :-) )for a while. > > johannes |
|
From: Furykid <fu...@us...> - 2002-01-18 22:51:07
|
Hi, Sorry chris I didnt find time to lok on your rmi reeimplementation but if you think it is necessary just go on !=20 There would have been a problem with my implementation anway, because of the user data passed all at once. for the new design please make it as extensible as possible for maybe some option will be added later. thanks again to you all for your support and have fun ! I am currently dealing with the IMAP protocoll integration, so the basecode will not change ( at least not from me :-) )for a while. johannes -----Original Message----- From: jma...@li... [mailto:jma...@li...] On Behalf Of Chris Davies Sent: Freitag, 18. J=E4nner 2002 23:36 To: Jma...@li... Subject: Re: [Jmailsrv-development] Web tier architecture Hi, OK, so we are agreed then? Right then, lets get on and write some code. I'll write some Web Configuration Client beans for accessing the server's configuration via RMI as soon as I hear from Johannes whether we should continue with the old RMI interface on the server, or use the new one that I wrote. I'll write a couple of interfaces first so that everbody else knows exactly what the backend will look like, so that you can get on writing the front end as soon as possible. Thanks, C.Davies Ben Clarke wrote: > Hi all, > From response to yesterday's post, it has become obvious that an XSLT > model is causing too much controversy to get off the ground. So as I=20 > understand it, this is the architecture that has been decided upon: > > o) the mail server web tier gets an HTTP request for the admin login=20 > page, which is a JSP. > > o) The form submit uses RMI to get the actual mail server to validate > the user, upon which either the login page is redisplayed (error=20 > msg?), or the administration JSP is called and displayed, by parsing=20 > the config XML file and presenting the data to the user. > > o) The user then posts the data back to the JSP, which uses RMI to=20 > send the updated info to the mail server. > > o) Depending on which values were updated, the JSP figures out=20 > whether a restart is necessary and if it is, a message is included in=20 > the returned HTML indicating so. > > That's all I can think of for the administration piece, but I think=20 > the Web Mail interface shouldn't be much different (except it actually > gets mail, marks as read etc. etc.). Please update me as to anything=20 > I've missed. > > So the question becomes, who does what? From what I understand the=20 > RMI stuff is substantially written, and Chris is working on the web=20 > tier code to talk to it. This pretty much leaves JSP's to be written=20 > as I see it, and Eugene and I to do it. Chris, if you're comfortable=20 > continuing to write RMI code, then Eugene, let's identify how many=20 > JSP's we need, what each does, and who should do it (assuming nobody=20 > has yet). > > One last thing, I am fine with moving on and going to a JSP model, but > Eugene, I don't think you gave my suggestions due credit or thought,=20 > specifically these points: > > EV> If there will be new options, what will you do with your xslt=20 > EV> file > ? Create new version each time ? > Yes, someone would absolutely have to make a new XSLT if the config=20 > XML file changed. However, the servlet may not even need recompiling=20 > if we were smart about it. Were you insinuating that with a JSP=20 > model, we wouldn't have to rewrite under the same circumstances? > > EV> Ok, there is nothing on this page, but usual java scriptlets. > What's the novelty ? It is convinient only for pages with really small > amount of code in background. Having used XSP first-hand, I can tell=20 > you that it is not merely useful for small amounts of Java code, I=20 > have written XSP's that have well over a hundred lines of Java code in > them which run beautifully. Also, I was not suggesting the use of=20 > XSP, merely pointing out that JSP is quickly becoming a dated=20 > technology. > > EV> And finally why it is better for our project ? > It is better for our project because it allows people to port the web=20 > UI to just about anything, including being used as an integrated=20 > backend mail system in larger apps of just about any language, without > writing or rewriting a single character of Java code, just the XSLT files used > to present that information. Also, it allows us to create > administration tools that are accessible from just about any device,=20 > including PDA's and Cellphones. If we are capable of putting more=20 > functionality into this product, why would we not? We do not know what > everyone will use it for or what their requirements will be, we are=20 > just the ones trying to satisfy everyone that does use it. > > EV> It's just usual marketing phrases. > Why would an organization that does not earn a cent, that is based on=20 > developer contributions exactly as this JMailSrv project is [the=20 > Apache group, makers of coccoon, the first XSP implementation], care=20 > about marketing or hype? Their main reason for existence is offering=20 > free implementations of standards created by people like the W3C. =20 > They only exist to make our lives easier. > > Have a good weekend all, > > Ben. > > _______________________________________________ > Jmailsrv-development mailing list=20 > Jma...@li... > https://lists.sourceforge.net/lists/listinfo/jmailsrv-development _______________________________________________ Jmailsrv-development mailing list Jma...@li... https://lists.sourceforge.net/lists/listinfo/jmailsrv-development |
|
From: Chris D. <c.d...@cd...> - 2002-01-18 22:38:45
|
Hi, OK, so we are agreed then? Right then, lets get on and write some code. I'll write some Web Configuration Client beans for accessing the server's configuration via RMI as soon as I hear from Johannes whether we should continue with the old RMI interface on the server, or use the new one that I wrote. I'll write a couple of interfaces first so that everbody else knows exactly what the backend will look like, so that you can get on writing the front end as soon as possible. Thanks, C.Davies Ben Clarke wrote: > Hi all, > From response to yesterday's post, it has become obvious that an XSLT > model is causing too much controversy to get off the ground. So as I > understand it, this is the architecture that has been decided upon: > > o) the mail server web tier gets an HTTP request for the admin login > page, which is a JSP. > > o) The form submit uses RMI to get the actual mail server to validate > the user, upon which either the login page is redisplayed (error msg?), > or the administration JSP is called and displayed, by parsing the config > XML file and presenting the data to the user. > > o) The user then posts the data back to the JSP, which uses RMI to send > the updated info to the mail server. > > o) Depending on which values were updated, the JSP figures out whether > a restart is necessary and if it is, a message is included in the > returned HTML indicating so. > > That's all I can think of for the administration piece, but I think the > Web Mail interface shouldn't be much different (except it actually gets > mail, marks as read etc. etc.). Please update me as to anything I've > missed. > > So the question becomes, who does what? From what I understand the RMI > stuff is substantially written, and Chris is working on the web tier > code to talk to it. This pretty much leaves JSP's to be written as I > see it, and Eugene and I to do it. Chris, if you're comfortable > continuing to write RMI code, then Eugene, let's identify how many JSP's > we need, what each does, and who should do it (assuming nobody has yet). > > One last thing, I am fine with moving on and going to a JSP model, but > Eugene, I don't think you gave my suggestions due credit or thought, > specifically these points: > > EV> If there will be new options, what will you do with your xslt file > ? Create new version each time ? > Yes, someone would absolutely have to make a new XSLT if the config XML > file changed. However, the servlet may not even need recompiling if we > were smart about it. Were you insinuating that with a JSP model, we > wouldn't have to rewrite under the same circumstances? > > EV> Ok, there is nothing on this page, but usual java scriptlets. > What's the novelty ? It is convinient only for pages with really small > amount of code in background. > Having used XSP first-hand, I can tell you that it is not merely useful > for small amounts of Java code, I have written XSP's that have well over > a hundred lines of Java code in them which run beautifully. Also, I was > not suggesting the use of XSP, merely pointing out that JSP is quickly > becoming a dated technology. > > EV> And finally why it is better for our project ? > It is better for our project because it allows people to port the web UI > to just about anything, including being used as an integrated backend > mail system in larger apps of just about any language, without writing > or rewriting a single character of Java code, just the XSLT files used > to present that information. Also, it allows us to create > administration tools that are accessible from just about any device, > including PDA's and Cellphones. If we are capable of putting more > functionality into this product, why would we not? We do not know what > everyone will use it for or what their requirements will be, we are just > the ones trying to satisfy everyone that does use it. > > EV> It's just usual marketing phrases. > Why would an organization that does not earn a cent, that is based on > developer contributions exactly as this JMailSrv project is [the Apache > group, makers of coccoon, the first XSP implementation], care about > marketing or hype? Their main reason for existence is offering free > implementations of standards created by people like the W3C. They only > exist to make our lives easier. > > Have a good weekend all, > > Ben. > > _______________________________________________ > Jmailsrv-development mailing list > Jma...@li... > https://lists.sourceforge.net/lists/listinfo/jmailsrv-development |
|
From: Ben C. <sky...@ro...> - 2002-01-18 22:23:48
|
Hi all, From response to yesterday's post, it has become obvious that an XSLT model is causing too much controversy to get off the ground. So as I understand it, this is the architecture that has been decided upon: o) the mail server web tier gets an HTTP request for the admin login page, which is a JSP. o) The form submit uses RMI to get the actual mail server to validate the user, upon which either the login page is redisplayed (error msg?), or the administration JSP is called and displayed, by parsing the config XML file and presenting the data to the user. o) The user then posts the data back to the JSP, which uses RMI to send the updated info to the mail server. o) Depending on which values were updated, the JSP figures out whether a restart is necessary and if it is, a message is included in the returned HTML indicating so. That's all I can think of for the administration piece, but I think the Web Mail interface shouldn't be much different (except it actually gets mail, marks as read etc. etc.). Please update me as to anything I've missed. So the question becomes, who does what? From what I understand the RMI stuff is substantially written, and Chris is working on the web tier code to talk to it. This pretty much leaves JSP's to be written as I see it, and Eugene and I to do it. Chris, if you're comfortable continuing to write RMI code, then Eugene, let's identify how many JSP's we need, what each does, and who should do it (assuming nobody has yet). One last thing, I am fine with moving on and going to a JSP model, but Eugene, I don't think you gave my suggestions due credit or thought, specifically these points: EV> If there will be new options, what will you do with your xslt file ? Create new version each time ? Yes, someone would absolutely have to make a new XSLT if the config XML file changed. However, the servlet may not even need recompiling if we were smart about it. Were you insinuating that with a JSP model, we wouldn't have to rewrite under the same circumstances? EV> Ok, there is nothing on this page, but usual java scriptlets. What's the novelty ? It is convinient only for pages with really small amount of code in background. Having used XSP first-hand, I can tell you that it is not merely useful for small amounts of Java code, I have written XSP's that have well over a hundred lines of Java code in them which run beautifully. Also, I was not suggesting the use of XSP, merely pointing out that JSP is quickly becoming a dated technology. EV> And finally why it is better for our project ? It is better for our project because it allows people to port the web UI to just about anything, including being used as an integrated backend mail system in larger apps of just about any language, without writing or rewriting a single character of Java code, just the XSLT files used to present that information. Also, it allows us to create administration tools that are accessible from just about any device, including PDA's and Cellphones. If we are capable of putting more functionality into this product, why would we not? We do not know what everyone will use it for or what their requirements will be, we are just the ones trying to satisfy everyone that does use it. EV> It's just usual marketing phrases. Why would an organization that does not earn a cent, that is based on developer contributions exactly as this JMailSrv project is [the Apache group, makers of coccoon, the first XSP implementation], care about marketing or hype? Their main reason for existence is offering free implementations of standards created by people like the W3C. They only exist to make our lives easier. Have a good weekend all, Ben. |
|
From: Eugene V. <gh...@ma...> - 2002-01-18 20:30:08
|
Hello Ben, If there will be new options, what will you do with your xslt file ? Create new version each time ? BC> A few notes on the feedback from my initial post: BC> With such technologies as XSP (http://xml.coverpages.org/WD-xsp-19990611.html, Ok, there is nothing on this page, but usual java scriptlets. What's the novelty ? It is convinient only for pages with really small amount of code in background. And what about using beans and tag libraries ? And finally why it is better for our project ? We are java developers and creating product for another developers, so why should we be afraid of some java code ? BC> note this article is 2 1/2 years old) being developed, JSP is losing ground to BC> standards-compliant means of accomplishing the same thing. It's just usual marketing phrases. Best regards, Eugene mailto:gh...@ma... |
|
From: Ben C. <sky...@ro...> - 2002-01-18 01:00:35
|
Hi guys, First, yes, I am very "with you", and have been keeping up to date on the mailing list posts. Having just read through the last 3 days' posts, this is how I see your current architecture for the admin config and web-based mail tool: Mail Server sitting potentially across geographic space from the web tier, which uses RMI to retrieve an XML config file to parse with proprietary code, populate a JSP page, and display to the user (assuming proper login credentials). I don't mean to be a broken record, but why parse the config XML into Java objects, then fill in the form with that? This architecture accomplishes the same thing but leaves out the manual XML parsing and form creation: Mail Server sitting across geographic space from web tier, which gets the config XML file over RMI, and passes it straight to an XSLT that operates on the config file itself (but _only_ for displaying its data, all updates to it happen elsewhere "the config file must not be directly written [fk]"). The XSLT creates HTML (or WML/HDML for administration from cellphones and PDA's, this is a fairly trivial addition*), with a form that posts back to the same servlet, which sends the data back over RMI to be put into the config file by the server itself. * I am NOT referring to having a web mail client available to these devices, I am specifically referring to administration, though in the long run we leave that option open by doing this. A few notes on the feedback from my initial post: 1. We are absolutely not creating Amazon.com or something like that here, but at the same time, we are providing a tool that (hopefully) people will continue to use for some time. With such technologies as XSP (http://xml.coverpages.org/WD-xsp-19990611.html, note this article is 2 1/2 years old) being developed, JSP is losing ground to standards-compliant means of accomplishing the same thing. 2. This model does use servlets, it just does not rely on proprietary means for creating the HTML to show the user. The following psuedo-doGet illustrates my point (uses javax.xml.transform classes, available with Apache Xalan... http://xml.apache.org): public void doGet(request, response) throws theUsualExceptionsAServletDoGetWould { response.setContentType("text/html; charset=UTF-8"); PrintWriter out = response.getWriter(); try { XMLConfigFile config = RMILayer.giveMeTheConfigFile(); // assuming it extends File, not even possible but simple for example... // this is the XSLT stuff TransformerFactory tf = TransformerFactory.newInstance(); Transformer t = tf.newTransformer(New StreamSource(URL_OF_XSLT_FILE)); t.transform(new StreamSource(new FileInputStream(config)), new StreamResult(out)); } catch(Exception e) { out.print("<html><body><p>Servlet Blew Up.</p></body></html>"); } } That way, nobody ever needs to see this code when they download the binary version. If there is a strong backing still to use JSP, then I concede, but I really believe there is a value-add in using an XML-based technology to display XML-based information. Any feedback is appreciated, unless you're pointing out the impossibility of sending a java.io.File across RMI ;-) . Anyway, now that I've spammed you all with my opinions, give me yours and let's solidify exactly what who is doing. I am comfortable writing JSP's if that is what we end up agreeing on, but let me know either way. Talk to you all soon, Ben. |
|
From: Eugene V. <gh...@ma...> - 2002-01-17 23:33:08
|
Hello Chris, CD> Don't forget that the web configuration tool must be able to add/edit/delete users as CD> well. This means the user file must be modified, not just used as a method of CD> authentication. This means we would have to pass it as we would the regular config CD> file. We can add it as one of properties in Settings Object.. It can be Map consisted of login Strings as keys and Lists with pass, rights, name, account name etc as values. CD> As regards understanding what properties the Settings Object has, this is what CD> Introspection is for. It is far quicker to to examine a Setttings Bean CD> introspectively than to reparse a flat file, and it also means we don't have to CD> mirror what could turn out to be a fairly complex parser in two places. Ok, let it be Setting Object, not direct xml file transferring. Thus, I guess, each property in this object should be of List type, containing info about option name, section, required rights etc. So main things are clear now, if there are any more objections or ideas, they are welcome.. Best regards, Eugene mailto:gh...@ma... |
|
From: Chris D. <c.d...@cd...> - 2002-01-17 21:42:15
|
Hi, Don't forget that the web configuration tool must be able to add/edit/delete users as well. This means the user file must be modified, not just used as a method of authentication. This means we would have to pass it as we would the regular config file. As regards understanding what properties the Settings Object has, this is what Introspection is for. It is far quicker to to examine a Setttings Bean introspectively than to reparse a flat file, and it also means we don't have to mirror what could turn out to be a fairly complex parser in two places. Thanks,. C.Davies Eugene Vogel wrote: > Hello Chris, > > CD> Well, there is at least one problem I can see with that appoach. User password > CD> data is stored in a seperate file from the main server config, and for good > CD> reason. We'd have to pass two files, one of which we don't really want to be > CD> distributed. > Well, I guess that authentication will be done by RMI. Client passes > login/pass and retrieves from serverside validity of user and his > rights (may be a name also etc). Whole file with login/pass info will not > be transferred. > CD> Plus, what is to stop us adding a third config file for some > CD> later extension? > I agree. But why do we need another config file ? Everything is in one > place now and adding new cfg files will be just a mess. And I guess, > that mail server is completed mostly, so in future there'll be not so > many new options.. > CD> Better I think to encapsulate the data in some sensibly defined Objects. > Hm.. If I understand you correctly, you mean, that cfg file will be parsed on > serverside, values will be tossed to properties of object, and this > object is passed. But this way we get a problem: if code on clientside > operates with already known type of object and looks for specific > properties, how will it understand that new options/properties were added ? > Thus, we will have to create an updated version of client each time we > add/change options. > > Best regards, Eugene mailto:gh...@ma... > > _______________________________________________ > Jmailsrv-development mailing list > Jma...@li... > https://lists.sourceforge.net/lists/listinfo/jmailsrv-development |
|
From: Eugene V. <gh...@ma...> - 2002-01-17 20:46:37
|
Hello Chris, CD> Well, there is at least one problem I can see with that appoach. User password CD> data is stored in a seperate file from the main server config, and for good CD> reason. We'd have to pass two files, one of which we don't really want to be CD> distributed. Well, I guess that authentication will be done by RMI. Client passes login/pass and retrieves from serverside validity of user and his rights (may be a name also etc). Whole file with login/pass info will not be transferred. CD> Plus, what is to stop us adding a third config file for some CD> later extension? I agree. But why do we need another config file ? Everything is in one place now and adding new cfg files will be just a mess. And I guess, that mail server is completed mostly, so in future there'll be not so many new options.. CD> Better I think to encapsulate the data in some sensibly defined Objects. Hm.. If I understand you correctly, you mean, that cfg file will be parsed on serverside, values will be tossed to properties of object, and this object is passed. But this way we get a problem: if code on clientside operates with already known type of object and looks for specific properties, how will it understand that new options/properties were added ? Thus, we will have to create an updated version of client each time we add/change options. Best regards, Eugene mailto:gh...@ma... |
|
From: Chris D. <c.d...@cd...> - 2002-01-17 18:58:58
|
Hi, Well, there is at least one problem I can see with that appoach. User password data is stored in a seperate file from the main server config, and for good reason. We'd have to pass two files, one of which we don't really want to be distributed. Plus, what is to stop us adding a third config file for some later extension? Better I think to encapsulate the data in some sensibly defined Objects. Thanks, C.Davies Eugene Vogel wrote: > Hello , > > Chris, wait a moment. Your point of view is exactly what I want to > implement. If the cfg file 'll be passed back and forth, there is no > need in client updating at all. Imagine, that our cfg file is xml, in > each entry there are following things: name of option, section to > which this option referred (server, logfiles etc), type of option > (string, int, boolean etc), rights that needed to view/change option > (admin, user), may be something more. > So when client gets this file, it just parses it till the end and > builds pages only with options and sections, that it has found in xml file. > If there 2 options in 1 section in xml file, only one page will be > generated, if 100 options in 10 sections, there'll be 10 pages. So we > do not need ever to update client. > CD> That way the format of config file is irrelevant to the configurator, > CD> and hence we can change it to XML or whatever when we > CD> get round to it. > Well, the reason is that xml is much easier to parse and also, > it's easier to add entries that I mentioned above (section, rights > etc) in hierarchic style. > > If you are not agree or see any better solution, please reply.. > > Best regards, Eugene mailto:gh...@ma... > > _______________________________________________ > Jmailsrv-development mailing list > Jma...@li... > https://lists.sourceforge.net/lists/listinfo/jmailsrv-development |
|
From: Eugene V. <gh...@ma...> - 2002-01-17 18:43:49
|
Hello , Chris, wait a moment. Your point of view is exactly what I want to implement. If the cfg file 'll be passed back and forth, there is no need in client updating at all. Imagine, that our cfg file is xml, in each entry there are following things: name of option, section to which this option referred (server, logfiles etc), type of option (string, int, boolean etc), rights that needed to view/change option (admin, user), may be something more. So when client gets this file, it just parses it till the end and builds pages only with options and sections, that it has found in xml file. If there 2 options in 1 section in xml file, only one page will be generated, if 100 options in 10 sections, there'll be 10 pages. So we do not need ever to update client. CD> That way the format of config file is irrelevant to the configurator, CD> and hence we can change it to XML or whatever when we CD> get round to it. Well, the reason is that xml is much easier to parse and also, it's easier to add entries that I mentioned above (section, rights etc) in hierarchic style. If you are not agree or see any better solution, please reply.. Best regards, Eugene mailto:gh...@ma... |
|
From: Chris D. <c.d...@cd...> - 2002-01-17 17:43:27
|
Hi, I have to disagree somewhat with Eugene said about passing the config file back and forth. This sounds like a bit of a nightmare when it comes to keeping both server and client updated. It means the server and client must both be exactly the same version. I propose that we design a plugin architecture for the config file, so that the Settings object contains not only the base server settings, but also a list of settings objects for any plugins that may be attached to the server. This way the client can render default pages for configuring plugins, even if it does not know about the plugin itself. That way the format of config file is irrelevant to the configurator, and hence we can change it to XML or whatever when we get round to it. Just my $0.02... Thanks, C.Davies |
|
From: Chris D. <c.d...@cd...> - 2002-01-17 17:07:20
|
Furykid wrote: > Hi, > > as mentioned earlier there is no need for the RMI interface to be > rewritten > ( except for additional parameters to be passed) Sorry to be a pain in the ass on this one, but I feel there really is a need for the user to have to authenticate with the server before they can get or set the settings. It was fine to allow unauthenticated users to connect from localhost, but from remote hosts this is a completely different story. Plus with a web front end, you have to be careful about mutiple people updating the config at once. For this reason, I went ahead and rewrote it. Knowing you views on the matter, I haven't commited it via CVS, but have a look at the classes I wrote and tell me what you think. You can find them here: http://www.cdavies.org/mailserv/ New features include: + Synchronised remote methods to avoid confusion over multiple users. + Session tracking on host and user name. + User authentication using password Things I'd like to implement: - Allow/Deny by host name, domain. If you can see anything wrong with the classes, give me a buzz and I\ll fix it. Thnaks, C.Davies |
|
From: Johannes P. <joh...@wa...> - 2002-01-17 08:58:00
|
Hi Eugen,
yes you are almost right :
there are 3 tiers ( mailserver, logic dealing with configuration retrival,
validation .., and serverside presentation)
so therefore:
.) user logs in through jsp ( or whatever) user data is either checked
against prefetched config data or directly
through RMI ( but in any case it is done by the 2nd tier ! the jsps itself
must not depend ony any implementation, nor are they allowed to
access a database or the config file !!)
.) yes - basically - if admin then serverconfiguration is accessable else
only inbox and user specific config ( which is almost nothing right now)
.) businesslogic ( for example servlet retrieves cfg data via RMI and acts
as controller) provides cfg data to presentation tier ( ie: jsps)
validates cfg data and commits data back to the mailserver through RMI
( where the cfg file or whatever will be written)
There is simply a value object wrapping up all config data which is passed
through RMI ( right now) but this might change to a more granular
implementation
depending on your ideas ! ( if you thing some other config params would be
necessary we might split this one object to some smaller ones)
at the moment all userdata is passed at once ( handy for small
configurations but unexaptable for complex environments...)
so for a fast start I suggest leaving the interface at it is, building jsp
( orwhatever...) pages for each of the configtool pages, and using the
existing
servercommunication. A bunch of jsps presenting the data and a backend
servlet doing the RMI communication would do it.
best regards
johannes
Eugene Vogel <gh...@ma...>
Gesendet von: An: "jmailsrv-development"
jma...@li...urc <jma...@li...>
eforge.net Kopie:
Thema: Re[2]: [Jmailsrv-development] Another new member
17.01.02 01:10
Bitte antworten an ghb
Hello Furykid,
Ok , so frontend should be like that :
- user logins in jsp, data is checked through jdbc database ( or passed
through RMI again ?).
- depending on user privileges, he will get webmail client (pure jsp)
and/or config tool.
- config tool retrieves cfg file by RMI, parses it and builds some
pages, each page is about appropriate section of cfg file. After
creating some changes, changes are committed, cfg file is generated
and passed back to the server, where actual writing take place.
F> .) The webfrontend should be able to run on a different tier ( dmz)
F> .) there should not be any clientside code ( applet)
F> .) Values are passed back to the mailserver using RMI
Ok, how can we get the values ? By RMI also ? And by the way, may be
it's better to pass not values, but whole cfg file, so it'll be
parsed on frontend. If the cfg file will be changed someday, we 'll
have to change the frontend. But if the whole cfg file transfers, it
can be easily parsed till the end on the fly right on clientside,
so there'll be no reason in changing client code. I suppose, that it will
be xml file and there will be some hints about different option's
appearance and possible value's types.
F> .) the config file must not be directly written.
So actual writings will take place on serverside ? This code is
already written ?
F> If you think there should be more or different settings or whatever just
F> let me know and I will prepare the necessary interface for you.
F> just focus on the representation and handling of the data.
If cfg file can be changed later, it's nearly necessary to migrate to
xml, it will possible to describe appearance of option.
F> Please make it possible to seperate user from server settings and a
F> possibility to extend the frontend by a webmail tool.
There is no problem. Access will depend on login/pass, so different
users will get different JSPs.
F> Just let me know what you think, and lets try to start working on this
F> task as soon as possible.
Ok, so Chris writes RMI part, I write the remaining. By the way, is Ben
with us ?
Best regards, Eugene mailto:gh...@ma...
_______________________________________________
Jmailsrv-development mailing list
Jma...@li...
https://lists.sourceforge.net/lists/listinfo/jmailsrv-development
|
|
From: Eugene V. <gh...@ma...> - 2002-01-17 00:11:24
|
Hello Furykid, Ok , so frontend should be like that : - user logins in jsp, data is checked through jdbc database ( or passed through RMI again ?). - depending on user privileges, he will get webmail client (pure jsp) and/or config tool. - config tool retrieves cfg file by RMI, parses it and builds some pages, each page is about appropriate section of cfg file. After creating some changes, changes are committed, cfg file is generated and passed back to the server, where actual writing take place. F> .) The webfrontend should be able to run on a different tier ( dmz) F> .) there should not be any clientside code ( applet) F> .) Values are passed back to the mailserver using RMI Ok, how can we get the values ? By RMI also ? And by the way, may be it's better to pass not values, but whole cfg file, so it'll be parsed on frontend. If the cfg file will be changed someday, we 'll have to change the frontend. But if the whole cfg file transfers, it can be easily parsed till the end on the fly right on clientside, so there'll be no reason in changing client code. I suppose, that it will be xml file and there will be some hints about different option's appearance and possible value's types. F> .) the config file must not be directly written. So actual writings will take place on serverside ? This code is already written ? F> If you think there should be more or different settings or whatever just F> let me know and I will prepare the necessary interface for you. F> just focus on the representation and handling of the data. If cfg file can be changed later, it's nearly necessary to migrate to xml, it will possible to describe appearance of option. F> Please make it possible to seperate user from server settings and a F> possibility to extend the frontend by a webmail tool. There is no problem. Access will depend on login/pass, so different users will get different JSPs. F> Just let me know what you think, and lets try to start working on this F> task as soon as possible. Ok, so Chris writes RMI part, I write the remaining. By the way, is Ben with us ? Best regards, Eugene mailto:gh...@ma... |
|
From: Furykid <fu...@us...> - 2002-01-16 22:27:24
|
Hi, as mentioned earlier there is no need for the RMI interface to be rewritten=20 ( except for additional parameters to be passed) it already there and its the only way to reconfigure the server without the need for a restart ( although this is not possible for all seetings). I think we first would need to specify the different tasks, descide which technology we will use and so on. .) The webfrontend should be able to run on a different tier ( dmz) .) there should not be any clientside code ( applet) .) Values are passed back to the mailserver using RMI .) the config file must not be directly written. I am quite familiar with jsps but not with XML based technology ( but in anyway I would like to focus on the server internals and let you do the web stuff as you are more skilled in this part) If you think there should be more or different settings or whatever just let me know and I will prepare the necessary interface for you. just focus on the representation and handling of the data. Please make it possible to seperate user from server settings and a possibility to extend the frontend by a webmail tool. Just let me know what you think, and lets try to start working on this task as soon as possible. best regards johannes -----Original Message----- From: jma...@li... [mailto:jma...@li...] On Behalf Of Chris Davies Sent: Mittwoch, 16. J=E4nner 2002 20:56 To: Jma...@li... Subject: Re: [Jmailsrv-development] Another new member Hi, I identified some key task areas for the web configuration front end in an earlier post. It can be found in the archive on sourceforge. I would suggest that these tasks were formalised and assigned to somebody. That way we each know what we are doing. I have begun work on the RMI interface with the server, which I guess all other tasks depend on at some stage or other, but if somebody would like me to work on something else, I'd be happy to comply. Thanks, C.Davies Eugene Vogel wrote: > Hello collegues ! > > Let's clear some things, finally. There are three people right now,=20 > that writes web frontend (Ben, Chris and me) and I don't understand,=20 > does somebody actually code now ? If no, let's share our thoughts and=20 > define design and who will write each section of code. > > About Ben Clarke message: > > BC> contributions you may find of value. For instance, I am (+/-)=20 > BC> fluent in XSL / XSLT, and if you guys like, I could write the HTML > BC> templates / XML generation code so that instead of using JSP's,=20 > BC> which require a restart of the application (I think) to replace,=20 > BC> we could have a number of XSL files that are interpreted at=20 > BC> run-time, equally fast and scalable, and more maintainable in that > BC> no knowledge of the JMailSrv API is necessary to change them, > Hm... Why we should know JMailSrv API ? Our task is to write cfg tool. > BC> just a knowledge of the XML schema (or DTD) which would come with > BC> a download of JMailSrv. (ie we abstract it so no Java code needs=20 > BC> writing to change the appearance of an HTML template). > I guess, there is absolutely no need in changing design ever. It's=20 > very simple and intended to give possibility of cfg file changing=20 > only. We're not writing Amazon.com or smthg like that here.. > BC> However, it means we don't need a JSP compiler package, obviously. > Ok, may be I don't understand smthg, you'll read data such way just=20 > fine. But how you'll write changed parameters back to the file ? And=20 > how you will retrieve data through RMI without JSP/servlets ? > > Best regards, Eugene mailto:gh...@ma... > > _______________________________________________ > Jmailsrv-development mailing list=20 > Jma...@li... > https://lists.sourceforge.net/lists/listinfo/jmailsrv-development _______________________________________________ Jmailsrv-development mailing list Jma...@li... https://lists.sourceforge.net/lists/listinfo/jmailsrv-development |
|
From: Chris D. <c.d...@cd...> - 2002-01-16 19:56:20
|
Hi, I identified some key task areas for the web configuration front end in an earlier post. It can be found in the archive on sourceforge. I would suggest that these tasks were formalised and assigned to somebody. That way we each know what we are doing. I have begun work on the RMI interface with the server, which I guess all other tasks depend on at some stage or other, but if somebody would like me to work on something else, I'd be happy to comply. Thanks, C.Davies Eugene Vogel wrote: > Hello collegues ! > > Let's clear some things, finally. There are three people right > now, that writes web frontend (Ben, Chris and me) and > I don't understand, does somebody actually code now ? If no, > let's share our thoughts and define design and who will write each > section of code. > > About Ben Clarke message: > > BC> contributions you may find of value. For instance, I am (+/-) fluent in > BC> XSL / XSLT, and if you guys like, I could write the HTML templates / XML > BC> generation code so that instead of using JSP's, which require a restart > BC> of the application (I think) to replace, we could have a number of XSL > BC> files that are interpreted at run-time, equally fast and scalable, and > BC> more maintainable in that no knowledge of the JMailSrv API is necessary > BC> to change them, > Hm... Why we should know JMailSrv API ? Our task is to write cfg tool. > BC> just a knowledge of the XML schema (or DTD) which would > BC> come with a download of JMailSrv. (ie we abstract it so no Java code > BC> needs writing to change the appearance of an HTML template). > I guess, there is absolutely no need in changing design ever. It's > very simple and intended to give possibility of cfg file changing > only. We're not writing Amazon.com or smthg like that here.. > BC> However, it means we don't need a JSP compiler package, obviously. > Ok, may be I don't understand smthg, you'll read data such way just > fine. But how you'll write changed parameters back to the file ? And > how you will retrieve data through RMI without JSP/servlets ? > > Best regards, Eugene mailto:gh...@ma... > > _______________________________________________ > Jmailsrv-development mailing list > Jma...@li... > https://lists.sourceforge.net/lists/listinfo/jmailsrv-development |
