Re: [ebxmlms-develop] Web admin and other contributions?

[Ronald v. K. <rv...@ab...>]

Patrick Yee wrote:

> Ronald,
>
> My apologies. Your previous mails in January have been staying in my 
> TODO mailbox for months. I wanted to review it but never have the time 
> to do so. :-(
>
No problem, I haven't been working on it anyway, since I've been 
focussing on an xforms implementation which we (me and some others) want 
to integrate into a BPM/WFM/B2B/EAI solution based on opensource 
projects (ebxmlms, chiba, jbpm all on sourceforge). Glad you responded 
now. btw, did you guys switch of the commit mailinglist? I thought there 
hadn't been any changes since january, but after doing a compare I saw 
there have been changes, and good ones imo.

> Hermes is an open source project. Clearly we should leverage on the 
> community effort to develop it. Therefore, we welcome your 
> contribution, the only obstacle out there is resource. Given this, it 
> would be helpful to us to keep the contribution incremental, so that 
> we can review and process the changes in a shorter time. If my 
> proposal is agreeable, we can work out a priority list for us to 
> process in the coming schedule.

I agree, it should be incremental. It contains three parts as I recall. 
(one of them is lost locally)
- using a jdbc datasource/connectionpool in stead of  the 'proprietary 
one'   : priority low-medium, impact: medium   (this one is lost locally)
- refactoring the MessageServiceHandler so there is easier (but secure!) 
access to the commands (e.g. for a web interface (dropping the swing gui 
would make it easier))
- refactoring the 'monitor' part of the MessageServiceHandler so other 
ways of sending messages could be achieved (e.g. a jms monitor ) : 
priority High impact medium

Things that make the refactoring difficult (although I think I've 
created a nice solution) is the deep dependency on the 
HttpServletRequest and HttpServletResponse objects. For receiving 
messages/commands from an application I've already made some changes. 
Probably not in the best way, It was just to see if it could be done. I 
had to change private/protected into public in some places, so 
securitywise it is probably not the best solution. Again, it was just to 
get an idea of the road ahead. One thing I have not looked into is the 
delivery of messages to an application. Since there is already a 
configurable way to define your own listeners I did not touch that.

>
>
> We are going to package and name the whole thing as 1.0. Before that, 
> we still have a couple of changes planned. Do you think your 
> contribution is mature enough to get into the 1.0 package?

Yes and no, the contribution is currently not to flexible configuration 
wise, although it has been running here since februari in a demo server 
(not doing to much I have to admit ;-) ). The contribution was 
primarily  to give an idea what the problems. I think a consesus has to 
be reached on how to refactor certain parts, which mainly are in the 
MessageServiceHandler. So no do not include it in the 1.0 release.

>
> Thank you for your effort!
>
Any time and thank you (all) for this product. I'm reviving a wiki I set 
up long ago do also discuss these things with the other people I'm 
working with. The main thing is that we should agree on a roadmap and 
then I/we have plenty of time available to work on this.  There are some 
other things we have in mind, but I think you'll see them appear on the 
wiki (I'll send the link once it is ready)

> Regards, -Patrick
>

Best,

Ronald