esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mrinal Wadhwa" <>
Subject Re: [VOTE] Web UI options
Date Wed, 07 Jan 2009 08:47:25 GMT
+1  Skip the intermediary Web UI and concentrate on the "BillF" UI?

I don't think an intermediate UI would be worth the effort


On Wed, Jan 7, 2009 at 1:49 PM, Hirsch, Richard

> >* Skip the intermediary Web UI and concentrate on the "BillF" UI?
> +1
> D.
> -----Urspr√ľngliche Nachricht-----
> Von: Hirsch, Richard
> Gesendet: Mittwoch, 07. Jänner 2009 09:18
> An:
> Betreff: [VOTE] Web UI options
> Last night on the scrum call, we were discussing various options for the
> Web UI and I wanted to summarize what we were discussing and ask the
> community on what option we should follow.
> -Situation-
> We currently have a Web UI running at the main ESME server at
> This version is very early iteration and has various
> issues associated with it.  It is also based on the old core code based
> at the Google Code site.  We now have a new new ESME core code base
> which is located at Apache. This version of the code at Apache is the
> most recent code base and includes a better split between UI and server
> code. The Apache version, however, currently doesn't have UI code in
> such maturity that we could use it to replace the existing Web site at
>  Bill has also created a description of a new ESME UI which
> probably depicts what the next UI is going to look like. This
> description is currently incomplete inasmuch as certain UI features are
> still not depicted.
> -Vote-
> The vote deals with the decision whether we want to build an
> intermediary Web-UI based on the existing Apache Core or whether we want
> to skip the intermediary Web UI and focus on the "BillF" UI?
> Choices (Please Vote!):
> * Create an intermediary UI
> * Skip the intermediary Web UI and concentrate on the "BillF" UI?
> Once the community makes a decision on this issue, we will define the
> associated tasks to support the decision.
> Dick
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message