Thread: RE: [Jmailsrv-development] Web tier architecture

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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