incubator-openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "seba.wagner@gmail.com" <seba.wag...@gmail.com>
Subject Re: [DISCUSS] Roadmap 2.1 and 3.0 version of OpenMeetings
Date Tue, 28 Aug 2012 10:08:39 GMT
There have been no votes against using OpenLaszlo and compile to
DHTML. However the OpenLaszlo project seems currently no more
maintained. There has been no release since 2010 of the project. The
comunity has downsized by factor of 10.
This is the community activity in the last years:
http://www.openlaszlo.org/pipermail/laszlo-dev/2012-June/024912.html

It is likely that if we are switching to DHTML that we will run into
issues as soon as new browser features of HTML5 will come up as the
Openlaszlo platform does not implement them. It would be actually our
task not only to develop OpenMeetings but also OpenLaszlo.

As DHTML compilation is a quite future orientated task I think we
should choose technology that support mobile devices and constantly
improves its cross-browser capibilities.

And last but not least the question is of course: How can we attract
new users? Chossing OpenLaszlo does actively look-out people as they
are not willing to learn it. We will have much better chances to find
new contributors if we choose a technology people are familiar with.

jQuery and Wicket do not bundle out of the box, simply because jQuery
is an UI framework and Wicket is a server side framework. There are
projects and components that combine jQuery and Wicket
code.google.com/p/wiquery/
code.google.com/p/jqwicket/
code.google.com/p/wickext/
code.google.com/p/wicket-jquery-ui/
www.7thweb.net/jquery-ui-samples/

And those are only the "projects" actually combining those
technologies needs nothing more then an import statement of the jQuery
library in the page header.

*It make little sense copying existing workflow. It adds value to
improve the workflow.*
=> I agree on that, however Flash is dead. We have to provide a DHTML
alternative. We will not replace our server side workflow.

*We need to add value to the product on any step. That makes us
user-oriented, not technology oriented.*
=> We will keep existing Flash frontend as long as its needed. It is
my intention to have a running OpenMeetings package all the time.

*Maybe we should use java management API and embed the existing
management console?
Maybe we should ship admin as a separate release bundle? Splitting
will help re-using other technologies.
Maybe we should ask designer guys on look & feel concept, and apply it
to our product?*
=> Sorry but now you are actually the one the broadens the whole
discussion to a much larger scale.
I agree with you that we need to define small steps to improve our project.
But having more modularization like "separate release bundle" has
actually nothing to do with DHTML compilation. It is just another
topic. Same as "ask designer guys on look & feel concept".
This is just not the topic of DHTML or not. You can do it regardless
if you compile DHTML or Flash.

Sebastian

2012/8/28 Alexei Fedotov <alexei.fedotov@gmail.com>:
> I do not stop people from volunteering. My thanks to Maxim for 1)
> proactivity; 2) good technology choice.
>
> I missed few items, Maxim told the first one is somewhere in the thread.
> 1. Why not to recompile OpenLaszlo to DHTML?
> 2. What is the plan and is it actually doable? What is time estimate?
>
> My friend who worked for our competior told me that they have
> re-written design four times during the last for years. We don't have
> resources for this. So my suggestion would be the following:
> 1. Find Openmeetings usability problems or most wanted features. Maybe
> Marco can help.
> 2. Develop that using new technology, making minor adjustments to
> already working things.
>
> So main concerns
> 1. It make little sense copying existing workflow. It adds value to
> improve the workflow.
> 2. We need to add value to the product on any step. That makes us
> user-oriented, not technology oriented.
>
> How good wicket is with jquery? It does not seem to work with jquery
> out of the box.
>
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> http://dataved.ru/
> +7 916 562 8095
>
>
> On Tue, Aug 28, 2012 at 11:51 AM, seba.wagner@gmail.com
> <seba.wagner@gmail.com> wrote:
>> What are your alternatives?
>> There are already people volunteering to start contributing to it.
>> It can be realized without breaking functionality, we still have the
>> Flash interface available while we build DHTML.
>>
>> Thanks!
>> Sebastian
>>
>> 2012/8/28 Alexei Fedotov <alexei.fedotov@gmail.com>:
>>> Guys, please do not rush, let me think a bit.
>>>
>>> --
>>> With best regards / с наилучшими пожеланиями,
>>> Alexei Fedotov / Алексей Федотов,
>>> http://dataved.ru/
>>> +7 916 562 8095
>>>
>>>
>>> On Mon, Aug 27, 2012 at 12:55 PM, seba.wagner@gmail.com
>>> <seba.wagner@gmail.com> wrote:
>>>> Ok
>>>>
>>>> 2012/8/27 Maxim Solodovnik <solomax666@gmail.com>:
>>>>> I prefer develop in trunk. I would vote for this
>>>>> On Aug 27, 2012 3:49 PM, "seba.wagner@gmail.com" <seba.wagner@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> That sounds good.
>>>>>> Do you want to create a new branch for the DHTML tree
>>>>>> or will trunk become the DHTML tree and we create a 2.1 branch ?
>>>>>>
>>>>>> Sebastian
>>>>>>
>>>>>> 2012/8/27 Maxim Solodovnik <solomax666@gmail.com>:
>>>>>> > We need to add following lines to our ivy.xml:
>>>>>> >
>>>>>> >                 <dependency org="org.apache.wicket" name="wicket-core"
>>>>>> > rev="6.0.0-beta3" conf="openmeetings->*"/>
>>>>>> >
>>>>>> > and that is all
>>>>>> >
>>>>>> > I can create "sample Om main page" and them both of as can add
>>>>>> components to it.
>>>>>> >
>>>>>> > On Mon, Aug 27, 2012 at 3:38 PM, seba.wagner@gmail.com
>>>>>> > <seba.wagner@gmail.com> wrote:
>>>>>> >> Wickets standard project setup require Maven. What is your
proposal to
>>>>>> >> integrate Wicket into the current stack?
>>>>>> >>
>>>>>> >> Sebastian
>>>>>> >>
>>>>>> >> 2012/8/27 Maxim Solodovnik <solomax666@gmail.com>:
>>>>>> >>> I don't really understand why do we need maven?
>>>>>> >>> Why ant+ivy is not enough?
>>>>>> >>> I always thought it is similar tools.
>>>>>> >>>
>>>>>> >>> Could you please explain it?
>>>>>> >>>
>>>>>> >>> On Mon, Aug 27, 2012 at 2:10 PM, seba.wagner@gmail.com
>>>>>> >>> <seba.wagner@gmail.com> wrote:
>>>>>> >>>> Well lets give it a try with Wicket.
>>>>>> >>>> However when it comes to the real collaboration
and UI effects I think
>>>>>> >>>> we will heavily use jQuery.
>>>>>> >>>> We will first have to integrate our application
in a Maven styled
>>>>>> project.
>>>>>> >>>>
>>>>>> >>>> I guess we can still use ANT to compile certain
aspect of our
>>>>>> >>>> application, Maven can trigger ANT build scripts.
>>>>>> >>>> http://maven.apache.org/plugins/maven-antrun-plugin/
>>>>>> >>>> seems to be a perfect tool for us.
>>>>>> >>>> However some of the Ivy dependency management might
be difficult to
>>>>>> >>>> set up. Lets try that out.
>>>>>> >>>>
>>>>>> >>>> Sebastian
>>>>>> >>>>
>>>>>> >>>> 2012/8/27 Maxim Solodovnik <solomax666@gmail.com>:
>>>>>> >>>>> Hello Sebastian,
>>>>>> >>>>>
>>>>>> >>>>> sorry for the late reply (was out of city with
no internet access)
>>>>>> >>>>> While proposing using Apache Wicket I thought
of following:
>>>>>> >>>>>
>>>>>> >>>>> 1) Displaying of lists: configuration, language
labels, rooms etc.
>>>>>> >>>>> 2) Use of Ajax to refresh only parts of page
displayed.
>>>>>> >>>>>
>>>>>> >>>>> We definitely can use JS libraries (like jQuery
UI) only but this
>>>>>> will
>>>>>> >>>>> make code less readable. I believe Apache Wicket
will be good for
>>>>>> >>>>> Admin menu etc. And we can easily add jQuery
UI to it.
>>>>>> >>>>>
>>>>>> >>>>> Instead of Wicket we can use Spring MVC and
Velocity.
>>>>>> >>>>> I have proposed Wicket only because I have more
experience with it
>>>>>> and
>>>>>> >>>>> from my point of view it is easy to maintain.
>>>>>> >>>>>
>>>>>> >>>>> On Mon, Aug 27, 2012 at 12:23 AM, seba.wagner@gmail.com
>>>>>> >>>>> <seba.wagner@gmail.com> wrote:
>>>>>> >>>>>> After some discussion I would like to propose
to integrate Apache
>>>>>> >>>>>> Wicket and try it out.
>>>>>> >>>>>> I have update the document:
>>>>>> >>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
>>>>>> >>>>>> Please add your notes.
>>>>>> >>>>>>
>>>>>> >>>>>> Thanks
>>>>>> >>>>>> Sebastian
>>>>>> >>>>>>
>>>>>> >>>>>> 2012/8/24 seba.wagner@gmail.com <seba.wagner@gmail.com>:
>>>>>> >>>>>>> This would be my proposal:
>>>>>> >>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal
>>>>>> >>>>>>>
>>>>>> >>>>>>> 2012/8/24 seba.wagner@gmail.com <seba.wagner@gmail.com>:
>>>>>> >>>>>>>> What if we instead of Apache Wicket
use Apache Velocity to
>>>>>> provide the
>>>>>> >>>>>>>> basic structure of the HTML websites?
>>>>>> >>>>>>>> All dynamically loaded data, rendering
of items could be then
>>>>>> done by jQuery.
>>>>>> >>>>>>>> That way we will have a set of html
templates to work on and a UI
>>>>>> >>>>>>>> framework to manipulate it.
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> Sebastian
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> 2012/8/24 seba.wagner@gmail.com
<seba.wagner@gmail.com>:
>>>>>> >>>>>>>>> I would like to share this use-case
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>> In the next iteration I would
like to put the Chat box as a
>>>>>> permanent
>>>>>> >>>>>>>>> box similar to what is in Google+
and Facebook on the bottom.
>>>>>> >>>>>>>>> That mean no matter where you
go, admin section, room list,
>>>>>> dashboard
>>>>>> >>>>>>>>> => the chat always stays
the same, so a complete page refresh is
>>>>>> not possible.
>>>>>> >>>>>>>>> I would simply replace the DIV
that contains the main content
>>>>>> with new
>>>>>> >>>>>>>>> one when switching between main
menu entries.
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>> What do you think about that?
>>>>>> >>>>>>>>> How would that affect the framework
discussion?
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>> Sebastian
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>> 2012/8/24 seba.wagner@gmail.com
<seba.wagner@gmail.com>:
>>>>>> >>>>>>>>>> When it comes to rendering
and UI component frameworks you come
>>>>>> to
>>>>>> >>>>>>>>>> projects like:
>>>>>> >>>>>>>>>> code.google.com/p/wiquery
>>>>>> >>>>>>>>>> http://www.7thweb.net/jquery-ui-samples/
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> Simple search for "Apache
Wicket UI samples" and you find tons
>>>>>> of
>>>>>> >>>>>>>>>> jQuery examples that are
used in Apache Wicket.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> So from my point of view
Apache Wicket is simply no UI
>>>>>> framework. It
>>>>>> >>>>>>>>>> is a web-framework. How
things render is not part of it.
>>>>>> Practically
>>>>>> >>>>>>>>>> it might mean that we could
combine Apache Wicket with jQuery
>>>>>> too. But
>>>>>> >>>>>>>>>> why use Apache Wicket then
at all? We have already a backend
>>>>>> with Rest
>>>>>> >>>>>>>>>> Services and everything.
Wicket would duplicate that. What
>>>>>> parts of
>>>>>> >>>>>>>>>> Wicket would we really use?
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> Sebastian
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> 2012/8/24 seba.wagner@gmail.com
<seba.wagner@gmail.com>:
>>>>>> >>>>>>>>>>> Can you show examples
of Apache Wicket UI widgets and
>>>>>> animation?
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>> Sebastian
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>> 2012/8/24 Maxim Solodovnik
<solomax666@gmail.com>:
>>>>>> >>>>>>>>>>>> I would recommend
to review Apache Wicket.
>>>>>> >>>>>>>>>>>> It is MVC it has
lots of UI components like paged lists table
>>>>>> views etc.
>>>>>> >>>>>>>>>>>> It had built-in
AJAX support.
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>> In general I'll
vote for moving to DHTML
>>>>>> >>>>>>>>>>>> On Aug 24, 2012
3:57 PM, "seba.wagner@gmail.com" <
>>>>>> seba.wagner@gmail.com>
>>>>>> >>>>>>>>>>>> wrote:
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> Hi,
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> I would like
to start a discussion about options to migrate
>>>>>> and a
>>>>>> >>>>>>>>>>>>> Roadmap for
the upcomfing versions.
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> This is our
current situation:
>>>>>> >>>>>>>>>>>>> We currently
have two client side application a) + b)
>>>>>> >>>>>>>>>>>>> a) Audio/Video
related stuff is all the SWF10 app
>>>>>> >>>>>>>>>>>>> b) whiteboard,
administration + all the rest in the SWF8 app.
>>>>>> >>>>>>>>>>>>> The two SWFs
communicate via LocalConnection with each other.
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> There are three
options from my point of view:
>>>>>> >>>>>>>>>>>>> 1) refactor
the SWF8 app to SWF11 and keep the
>>>>>> LocalConnection
>>>>>> >>>>>>>>>>>>> 2) refactor
the SWF8 and merge SWF8 with SWF10 app to a
>>>>>> single SWF11
>>>>>> >>>>>>>>>>>>> app and get
rid of the LocalConnection workaround
>>>>>> >>>>>>>>>>>>> 3) refactor
the SWF8 app to HTML5 and only use SWF for the
>>>>>> audio/video
>>>>>> >>>>>>>>>>>>> part.
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> option 1 is
the easiest thing to do
>>>>>> >>>>>>>>>>>>> option 2 is
the best from architecture point of view
>>>>>> >>>>>>>>>>>>> option 3 is
the best for moving to HTML5
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> From my point
of view it would be the best option to start
>>>>>> DHTML
>>>>>> >>>>>>>>>>>>> refactoring
now (in a version 3.0 branch) and release the
>>>>>> current
>>>>>> >>>>>>>>>>>>> trunk tree (as
version 2.1).
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> For the transition
to DHTML we have several options:
>>>>>> >>>>>>>>>>>>> I) Refactor
to DHTML using OpenLaszlo
>>>>>> >>>>>>>>>>>>> II) Refactor
to DHTML using a JavaScript framework (jQuery,
>>>>>> Dojo,
>>>>>> >>>>>>>>>>>>> Apache Wicket,
Spring+MVC)
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> My personal
preference is using jQuery. It provides
>>>>>> components for UI
>>>>>> >>>>>>>>>>>>> and animation
and is the most widespread. From a project
>>>>>> point of view
>>>>>> >>>>>>>>>>>>> it will be more
easy to attract new developers if they can
>>>>>> use tools
>>>>>> >>>>>>>>>>>>> that they are
comfortable in. And I really don't want to
>>>>>> code a client
>>>>>> >>>>>>>>>>>>> side application
that requires heavy usage of the
>>>>>> page-refresh. That
>>>>>> >>>>>>>>>>>>> would be like
moving back in time.
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> There are some
architectural questions that we should
>>>>>> discuss for the
>>>>>> >>>>>>>>>>>>> JavaScript refactoring.
>>>>>> >>>>>>>>>>>>> However there
should be some kind of consens on the overall
>>>>>> RoadMap first.
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> So what do you
think?
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> Sebastian
>>>>>> >>>>>>>>>>>>> --
>>>>>> >>>>>>>>>>>>> Sebastian Wagner
>>>>>> >>>>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>> >>>>>>>>>>>>> http://www.webbase-design.de
>>>>>> >>>>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>> >>>>>>>>>>>>> seba.wagner@gmail.com
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>> --
>>>>>> >>>>>>>>>>> Sebastian Wagner
>>>>>> >>>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>> >>>>>>>>>>> http://www.webbase-design.de
>>>>>> >>>>>>>>>>> http://www.wagner-sebastian.com
>>>>>> >>>>>>>>>>> seba.wagner@gmail.com
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> --
>>>>>> >>>>>>>>>> Sebastian Wagner
>>>>>> >>>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>> >>>>>>>>>> http://www.webbase-design.de
>>>>>> >>>>>>>>>> http://www.wagner-sebastian.com
>>>>>> >>>>>>>>>> seba.wagner@gmail.com
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>> --
>>>>>> >>>>>>>>> Sebastian Wagner
>>>>>> >>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>> >>>>>>>>> http://www.webbase-design.de
>>>>>> >>>>>>>>> http://www.wagner-sebastian.com
>>>>>> >>>>>>>>> seba.wagner@gmail.com
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> --
>>>>>> >>>>>>>> Sebastian Wagner
>>>>>> >>>>>>>> https://twitter.com/#!/dead_lock
>>>>>> >>>>>>>> http://www.webbase-design.de
>>>>>> >>>>>>>> http://www.wagner-sebastian.com
>>>>>> >>>>>>>> seba.wagner@gmail.com
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>> --
>>>>>> >>>>>>> Sebastian Wagner
>>>>>> >>>>>>> https://twitter.com/#!/dead_lock
>>>>>> >>>>>>> http://www.webbase-design.de
>>>>>> >>>>>>> http://www.wagner-sebastian.com
>>>>>> >>>>>>> seba.wagner@gmail.com
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>> --
>>>>>> >>>>>> Sebastian Wagner
>>>>>> >>>>>> https://twitter.com/#!/dead_lock
>>>>>> >>>>>> http://www.webbase-design.de
>>>>>> >>>>>> http://www.wagner-sebastian.com
>>>>>> >>>>>> seba.wagner@gmail.com
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> --
>>>>>> >>>>> WBR
>>>>>> >>>>> Maxim aka solomax
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> --
>>>>>> >>>> Sebastian Wagner
>>>>>> >>>> https://twitter.com/#!/dead_lock
>>>>>> >>>> http://www.webbase-design.de
>>>>>> >>>> http://www.wagner-sebastian.com
>>>>>> >>>> seba.wagner@gmail.com
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> --
>>>>>> >>> WBR
>>>>>> >>> Maxim aka solomax
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Sebastian Wagner
>>>>>> >> https://twitter.com/#!/dead_lock
>>>>>> >> http://www.webbase-design.de
>>>>>> >> http://www.wagner-sebastian.com
>>>>>> >> seba.wagner@gmail.com
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > WBR
>>>>>> > Maxim aka solomax
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sebastian Wagner
>>>>>> https://twitter.com/#!/dead_lock
>>>>>> http://www.webbase-design.de
>>>>>> http://www.wagner-sebastian.com
>>>>>> seba.wagner@gmail.com
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sebastian Wagner
>>>> https://twitter.com/#!/dead_lock
>>>> http://www.webbase-design.de
>>>> http://www.wagner-sebastian.com
>>>> seba.wagner@gmail.com
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Mime
View raw message