I have no public server to run this. You can run it locally: 1) svn up 2) edit web.xml (uncomment Wicket Filter) 3) ant -Ddb=mysql 4) http://localhost:5080/openmeetings
On Thu, Aug 30, 2012 at 2:42 PM, Alexei Fedotov <[email protected]> wrote: > Maxim, that's great! > Can I check a demo somewhere? > > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://dataved.ru/ > +7 916 562 8095 > > > On Wed, Aug 29, 2012 at 10:50 PM, Maxim Solodovnik <[email protected]> > wrote: >> Just have commited Initial "HelloWorld" OM Wicket application (to use >> need to uncomment wicket filter in web.xml) >> >> What was done: >> 1) Wicket is starts and handle pages >> 2) All OM labels are displayed from DB >> 3) You can login using your OM username/pass (login dialog uses jQuery >> UI dialog) >> 4) OM user levels are in effect (user or admin) >> 5) OM Navi menu is displayed from the DB >> 6) Navi link to Admin users page displays stub for admin users page >> >> What was not done: >> 1) wicket currently handles all URLs (this is why it is currently commented) >> 2) Entity list is not displayed from the DB as paged table (going to >> do as next task) >> >> Please take a look and tell me what do you think? >> >> On Tue, Aug 28, 2012 at 5:08 PM, [email protected] >> <[email protected]> wrote: >>> 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 <[email protected]>: >>>> 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, [email protected] >>>> <[email protected]> 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 <[email protected]>: >>>>>> 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, [email protected] >>>>>> <[email protected]> wrote: >>>>>>> Ok >>>>>>> >>>>>>> 2012/8/27 Maxim Solodovnik <[email protected]>: >>>>>>>> I prefer develop in trunk. I would vote for this >>>>>>>> On Aug 27, 2012 3:49 PM, "[email protected]" >>>>>>>> <[email protected]> >>>>>>>> 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 <[email protected]>: >>>>>>>>> > 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, [email protected] >>>>>>>>> > <[email protected]> wrote: >>>>>>>>> >> Wickets standard project setup require Maven. What is your >>>>>>>>> >> proposal to >>>>>>>>> >> integrate Wicket into the current stack? >>>>>>>>> >> >>>>>>>>> >> Sebastian >>>>>>>>> >> >>>>>>>>> >> 2012/8/27 Maxim Solodovnik <[email protected]>: >>>>>>>>> >>> 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, [email protected] >>>>>>>>> >>> <[email protected]> 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 <[email protected]>: >>>>>>>>> >>>>> 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, [email protected] >>>>>>>>> >>>>> <[email protected]> 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 [email protected] <[email protected]>: >>>>>>>>> >>>>>>> This would be my proposal: >>>>>>>>> >>>>>>> >>>>>>>>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> 2012/8/24 [email protected] <[email protected]>: >>>>>>>>> >>>>>>>> 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 [email protected] <[email protected]>: >>>>>>>>> >>>>>>>>> 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 [email protected] <[email protected]>: >>>>>>>>> >>>>>>>>>> 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 [email protected] <[email protected]>: >>>>>>>>> >>>>>>>>>>> Can you show examples of Apache Wicket UI widgets and >>>>>>>>> animation? >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> Sebastian >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> 2012/8/24 Maxim Solodovnik <[email protected]>: >>>>>>>>> >>>>>>>>>>>> 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, "[email protected]" < >>>>>>>>> [email protected]> >>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>>>>>> [email protected] >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>>>> -- >>>>>>>>> >>>>>>>>>>> Sebastian Wagner >>>>>>>>> >>>>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>> >>>>>>>>>>> http://www.webbase-design.de >>>>>>>>> >>>>>>>>>>> http://www.wagner-sebastian.com >>>>>>>>> >>>>>>>>>>> [email protected] >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> -- >>>>>>>>> >>>>>>>>>> Sebastian Wagner >>>>>>>>> >>>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>> >>>>>>>>>> http://www.webbase-design.de >>>>>>>>> >>>>>>>>>> http://www.wagner-sebastian.com >>>>>>>>> >>>>>>>>>> [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Sebastian Wagner >>>>>>>>> >>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>> >>>>>>>>> http://www.webbase-design.de >>>>>>>>> >>>>>>>>> http://www.wagner-sebastian.com >>>>>>>>> >>>>>>>>> [email protected] >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>>> >>>>>>>> Sebastian Wagner >>>>>>>>> >>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>> >>>>>>>> http://www.webbase-design.de >>>>>>>>> >>>>>>>> http://www.wagner-sebastian.com >>>>>>>>> >>>>>>>> [email protected] >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> -- >>>>>>>>> >>>>>>> Sebastian Wagner >>>>>>>>> >>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>> >>>>>>> http://www.webbase-design.de >>>>>>>>> >>>>>>> http://www.wagner-sebastian.com >>>>>>>>> >>>>>>> [email protected] >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> -- >>>>>>>>> >>>>>> Sebastian Wagner >>>>>>>>> >>>>>> https://twitter.com/#!/dead_lock >>>>>>>>> >>>>>> http://www.webbase-design.de >>>>>>>>> >>>>>> http://www.wagner-sebastian.com >>>>>>>>> >>>>>> [email protected] >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> -- >>>>>>>>> >>>>> WBR >>>>>>>>> >>>>> Maxim aka solomax >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> -- >>>>>>>>> >>>> Sebastian Wagner >>>>>>>>> >>>> https://twitter.com/#!/dead_lock >>>>>>>>> >>>> http://www.webbase-design.de >>>>>>>>> >>>> http://www.wagner-sebastian.com >>>>>>>>> >>>> [email protected] >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> -- >>>>>>>>> >>> WBR >>>>>>>>> >>> Maxim aka solomax >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> -- >>>>>>>>> >> Sebastian Wagner >>>>>>>>> >> https://twitter.com/#!/dead_lock >>>>>>>>> >> http://www.webbase-design.de >>>>>>>>> >> http://www.wagner-sebastian.com >>>>>>>>> >> [email protected] >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > -- >>>>>>>>> > WBR >>>>>>>>> > Maxim aka solomax >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Sebastian Wagner >>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>> http://www.webbase-design.de >>>>>>>>> http://www.wagner-sebastian.com >>>>>>>>> [email protected] >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sebastian Wagner >>>>>>> https://twitter.com/#!/dead_lock >>>>>>> http://www.webbase-design.de >>>>>>> http://www.wagner-sebastian.com >>>>>>> [email protected] >>>>> >>>>> >>>>> >>>>> -- >>>>> Sebastian Wagner >>>>> https://twitter.com/#!/dead_lock >>>>> http://www.webbase-design.de >>>>> http://www.wagner-sebastian.com >>>>> [email protected] >>> >>> >>> >>> -- >>> Sebastian Wagner >>> https://twitter.com/#!/dead_lock >>> http://www.webbase-design.de >>> http://www.wagner-sebastian.com >>> [email protected] >> >> >> >> -- >> WBR >> Maxim aka solomax -- WBR Maxim aka solomax
