Maxim, just one thing: The "new" implemention will of course also "silently" overwrite the timezone string with every login. Otherwise we would send invitations to that user in a potentially wrong configured timezone.
2013/8/10 seba.wag...@gmail.com <seba.wag...@gmail.com> > My vote is also 2. I will create a couple of jiras later today. > We can create a feature branch based on trunk and do the work inside that. > > Sebastian > On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru> wrote: > >> My vote is for Alternative 2. >> >> Vasiliy >> >> >> On 09.08.2013 14:24, seba.wag...@gmail.com wrote: >> >>> So probably we can put this up for a vote? >>> >>> The only alternative I see as a short term fix is to overwrite the users >>> "OmTimeZone" with the current timezone of the browser. >>> >>> Alternative 1: >>> Short term fix, default OmTimeZone to current timezone in browser, >>> overwrite everytime the user logs in (Estimated 1-2 weeks of work) >>> >>> Alternative 2: >>> Rewrite and refactor to get rid of entire OmTimeZone (as described in >>> attached discussion or thread: http://markmail.org/message/** >>> rem2snf74srvftnt <http://markmail.org/message/rem2snf74srvftnt>) >>> (Estimated 1-2 months of work) >>> >>> The effort estimates are including time that is needed for fixing bugs >>> and >>> do the testing. >>> >>> Vote for 1 if you like to see this implemented as part of OpenMeetings >>> 3.0.0, vote for Alternative 2 if you want to see this implemented as part >>> of OpenMeetings 3.0.0. >>> >>> Thanks, >>> Sebastian >>> >>> >>> 2013/8/8 seba.wag...@gmail.com <seba.wag...@gmail.com> >>> >>> That is the major question. >>>> >>>> Basically status now is that the Calendar UI is not ready to be >>>> released. >>>> The UI is simply not working when your browser timezone is different >>>> from >>>> the timezone in your OpenMeetings profile. >>>> >>>> So either we can do the proposed fixes around getting rid of the >>>> OmTimeZone completely or we try to do some kind of workaround in >>>> OpenMeetings 3.0.0 and do the refactoring later. >>>> >>>> Sebastian >>>> >>>> >>>> 2013/8/7 Maxim Solodovnik <solomax...@gmail.com> >>>> >>>> Can we define any useful JUnit tests so that we don't need to do so >>>>>>>> >>>>>>> much manual testing ? >>>>> I believe so, but what version will be affected with this change? >>>>> 3.0.0 or >>>>> 3.1.0? >>>>> >>>>> >>>>> On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com < >>>>> seba.wag...@gmail.com >>>>> >>>>>> wrote: >>>>>> "I would default server time zone to the time zone of the server. >>>>>> It is up to admin to set it to the different value." >>>>>> ok >>>>>> >>>>>> "Additionally Appointment, I guess." >>>>>> Nope, Appointment does not have timezone information. The start/end >>>>>> >>>>> date of >>>>> >>>>>> the appointment is always in the server time zone. Actually _an_ >>>>>> >>>>> date/time >>>>> >>>>>> that is stored is always the server time. >>>>>> We only need timezone information when we need to display that time >>>>>> for >>>>>> >>>>> any >>>>> >>>>>> _user_ to generate a localized representation of the date/time. >>>>>> For instance an Appointment can be 8am GMT but for one user 1am >>>>>> >>>>> GMT/Berlin >>>>> >>>>>> should be displayed as 6pm NZDT/Auckland and for yet another >>>>>> >>>>> MeetingMember >>>>> >>>>>> it has to be displayed as 2am EDT/New York. >>>>>> >>>>>> So from my point of view the User, MeetingMember and Invitations >>>>>> Entity >>>>>> >>>>> are >>>>> >>>>>> the right place. And that is already as it is now. So you can replace >>>>>> OmTimeZone in all those classes with the new attribute that stored the >>>>>> timezone. >>>>>> >>>>>> Can we define any useful JUnit tests so that we don't need to do so >>>>>> much >>>>>> manual testing ? >>>>>> >>>>>> Sebastian >>>>>> >>>>>> >>>>>> >>>>>> 2013/8/7 Maxim Solodovnik <solomax...@gmail.com> >>>>>> >>>>>> I would default server time zone to the time zone of the server. >>>>>>> It is up to admin to set it to the different value. >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com < >>>>>>> seba.wag...@gmail.com> wrote: >>>>>>> >>>>>>> I basically don't mind about the component in the UI. I just thought >>>>>>>> initially that 650 in a combobox is too much. >>>>>>>> However it does not seem to be an issue for the UI as such. >>>>>>>> >>>>>>>> My basic question is what we use as default: Do we default to the >>>>>>>> >>>>>>> server >>>>>> >>>>>>> timezone or to the client site user timezone ? >>>>>>>> >>>>>>>> Sebastian >>>>>>>> >>>>>>>> >>>>>>>> 2013/8/7 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>> >>>>>>>> The correct URL is http://timezonepicker.com/ >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik < >>>>>>>>> >>>>>>>> solomax...@gmail.com >>>>>> >>>>>>> wrote: >>>>>>>>>> I believe we can use something like this: >>>>>>>>>> >>>>>>>>> https://timezonepicker.com >>>>>> >>>>>>> (sources are here: >>>>>>>>>> >>>>>>>>> https://github.com/**quicksketch/timezonepicker<https://github.com/quicksketch/timezonepicker> >>>>> ) >>>>> >>>>>> The only issues I can see right now: >>>>>>>>>> 1) it has no License set in the moment ( >>>>>>>>>> https://github.com/**quicksketch/timezonepicker/**issues/2<https://github.com/quicksketch/timezonepicker/issues/2> >>>>>>>>>> ) >>>>>>>>>> 2) It last updated 9 months ago >>>>>>>>>> >>>>>>>>>> So maybe additional googling is required :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Aug 7, 2013 at 4:50 AM, seba.wag...@gmail.com < >>>>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> One thing that is not on our list now is the default timezone >>>>>>>>>>> >>>>>>>>>> of >>>>> >>>>>> the >>>>>> >>>>>>> server. >>>>>>>>>>> Currently when you install OpenMeetings you choose a timezone. >>>>>>>>>>> >>>>>>>>>>> The questions are: >>>>>>>>>>> 1) Where do we populate the timezones from in that list, >>>>>>>>>>> >>>>>>>>>> displaying >>>>>> >>>>>>> 650 >>>>>>>> >>>>>>>>> timezones of java.util.Timezone is not practical >>>>>>>>>>> 2) If we default that timezone to some value, what shall it >>>>>>>>>>> >>>>>>>>>> be? >>>>> >>>>>> The >>>>>> >>>>>>> timezone of the server or the timezone of the client browser? >>>>>>>>>>> => In theory this default timezone is used whenever we >>>>>>>>>>> >>>>>>>>>> can't >>>>> >>>>>> find a >>>>>>>> >>>>>>>>> suitable timezone. So potentially we can default it to the >>>>>>>>>>> >>>>>>>>>> browsers >>>>>> >>>>>>> timezone that is currently installing OpenMeetings. >>>>>>>>>>> This default timzeone will be used whenever there is no >>>>>>>>>>> >>>>>>>>>> timezone >>>>>>> >>>>>>>> available for a user or if the timezone of the user is >>>>>>>>>>> >>>>>>>>>> corrupted. >>>>> >>>>>> Sebastian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2013/8/6 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>>>>> >>>>>>>>>>> Additionally Appointment, I guess. >>>>>>>>>>>> Non-existent XML attribute will be ignored by >>>>>>>>>>>> >>>>>>>>>>> simpleframework. >>>>> >>>>>> I believe we can let timezones.xml live in our sources and >>>>>>>>>>>> >>>>>>>>>>> convert >>>>>> >>>>>>> backups >>>>>>>>>>> >>>>>>>>>>>> based on it >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Aug 6, 2013 at 5:28 PM, seba.wag...@gmail.com < >>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> That might be another approach. >>>>>>>>>>>>> So you are saying we get rid of the Entity OmTimeZone in >>>>>>>>>>>>> >>>>>>>>>>>> total? >>>>>> >>>>>>> Even if we have the timezone in the each of those object,I >>>>>>>>>>>>> >>>>>>>>>>>> think >>>>>> >>>>>>> there >>>>>>>>> >>>>>>>>>> should be a fallback mechanism. Cause with every Java >>>>>>>>>>>>> >>>>>>>>>>>> update >>>>> >>>>>> (or I >>>>>>> >>>>>>>> think >>>>>>>>>>> >>>>>>>>>>>> you can even do it manually) you can get updates to the >>>>>>>>>>>>> >>>>>>>>>>>> number/offset >>>>>>>>> >>>>>>>>>> of >>>>>>>>>>> >>>>>>>>>>>> the timezones (appearently every year such and such >>>>>>>>>>>>> >>>>>>>>>>>> countries >>>>> >>>>>> for >>>>>>> >>>>>>>> instance >>>>>>>>>>>> >>>>>>>>>>>>> "decide" to switch to have not a Daylight saving time, et >>>>>>>>>>>>> >>>>>>>>>>>> cetera, >>>>>>> >>>>>>>> or >>>>>>>> >>>>>>>>> there >>>>>>>>>>>> >>>>>>>>>>>>> is even a brand new timezone). >>>>>>>>>>>>> So it could happen one day that we have timezone string in >>>>>>>>>>>>> >>>>>>>>>>>> our >>>>> >>>>>> application >>>>>>>>>>>> >>>>>>>>>>>>> that is neither known to java.util.Timezone nor to >>>>>>>>>>>>> net.fortuna.ical4j.model.**TimeZone. Or a timezone exists in >>>>>>>>>>>>> >>>>>>>>>>>> the >>>>> >>>>>> one >>>>>>> >>>>>>>> and >>>>>>>>> >>>>>>>>>> does >>>>>>>>>>>> >>>>>>>>>>>>> not exist in the other. >>>>>>>>>>>>> >>>>>>>>>>>>> I think we should go the extra mile and try to outline the >>>>>>>>>>>>> >>>>>>>>>>>> technical >>>>>>>> >>>>>>>>> part >>>>>>>>>>> >>>>>>>>>>>> upfront doing anything concretly. It could save us a lot of >>>>>>>>>>>>> >>>>>>>>>>>> time. >>>>>>> >>>>>>>> Also it >>>>>>>>>>> >>>>>>>>>>>> might be good to discuss this publicly as more then one >>>>>>>>>>>>> >>>>>>>>>>>> person >>>>> >>>>>> can >>>>>>> >>>>>>>> then >>>>>>>>>>> >>>>>>>>>>>> work on it in parallel. >>>>>>>>>>>>> >>>>>>>>>>>>> As far as I can judge you can't save the type >>>>>>>>>>>>> >>>>>>>>>>>> java.util.Timezone >>>>>> >>>>>>> in >>>>>>>> >>>>>>>>> a >>>>>>>>> >>>>>>>>>> database. >>>>>>>>>>>>> So it has to be either a string or you store an Integer >>>>>>>>>>>>> (utcTimeZoneOffset). But I really don't like the latter as >>>>>>>>>>>>> >>>>>>>>>>>> it >>>>> >>>>>> does >>>>>>> >>>>>>>> not >>>>>>>>> >>>>>>>>>> handle Daylight savings times. >>>>>>>>>>>>> >>>>>>>>>>>>> So the Entities that hold an attribute "omTimeZone" that >>>>>>>>>>>>> >>>>>>>>>>>> would >>>>> >>>>>> need >>>>>>>> >>>>>>>>> to be >>>>>>>>>>> >>>>>>>>>>>> changed: >>>>>>>>>>>>> User >>>>>>>>>>>>> Invitations >>>>>>>>>>>>> MeetingMembers >>>>>>>>>>>>> >>>>>>>>>>>>> and they all get a new attribute "String tz" >>>>>>>>>>>>> >>>>>>>>>>>>> How would we imagine could the export and import work if >>>>>>>>>>>>> >>>>>>>>>>>> you >>>>> >>>>>> import >>>>>>>> >>>>>>>>> an >>>>>>>>> >>>>>>>>>> old >>>>>>>>>>>> >>>>>>>>>>>>> backup where the OmTimeZone is set in the user? I guess we >>>>>>>>>>>>> >>>>>>>>>>>> need >>>>>> >>>>>>> a >>>>>>> >>>>>>>> converter >>>>>>>>>>>> >>>>>>>>>>>>> that can handle OmTimeZone to the new format. >>>>>>>>>>>>> However would that even work currently with >>>>>>>>>>>>> org.simpleframework.xml.**Element, when you have an attribute >>>>>>>>>>>>> >>>>>>>>>>>> that >>>>>> >>>>>>> does >>>>>>>>> >>>>>>>>>> just >>>>>>>>>>>> >>>>>>>>>>>>> no more exist ? >>>>>>>>>>>>> >>>>>>>>>>>>> Any other considerations that are not yet covered? >>>>>>>>>>>>> >>>>>>>>>>>>> Sebastian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2013/8/6 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>>>>>>> >>>>>>>>>>>>> I like the idea of having less custom issues >>>>>>>>>>>>>> I believe TZ field in all our objects can easily be just >>>>>>>>>>>>>> >>>>>>>>>>>>> a >>>>> >>>>>> string >>>>>>>> >>>>>>>>> like: >>>>>>>>>>> >>>>>>>>>>>> "Europe/Berlin" >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Aug 6, 2013 at 3:36 PM, Maxim Solodovnik < >>>>>>>>>>>>>> >>>>>>>>>>>>> solomax...@gmail.com >>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> I have: It is impossible to get User timezone (you only >>>>>>>>>>>>>>> >>>>>>>>>>>>>> can >>>>>> >>>>>>> get >>>>>>>> >>>>>>>>> tz >>>>>>>>> >>>>>>>>>> shift >>>>>>>>>>>>> >>>>>>>>>>>>>> and/or dst shift and if dst is in effect) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> According to iCal4J time zone mapping I guess the name >>>>>>>>>>>>>>> >>>>>>>>>>>>>> should >>>>>>> >>>>>>>> be >>>>>>>> >>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>>> same >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Aug 6, 2013 at 3:17 PM, seba.wag...@gmail.com< >>>>>>>>>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Okay, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> after a bit of back and forth using the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wicket-jquery-ui >>>>> >>>>>> library >>>>>>>>> >>>>>>>>>> I >>>>>>>>>>> >>>>>>>>>>>> think >>>>>>>>>>>>> >>>>>>>>>>>>>> it >>>>>>>>>>>>>>>> might be worth re-evaluating our timezone behaviour. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Basically it seems like the approach to show the UI >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> in a >>>>> >>>>>> timezone >>>>>>>>> >>>>>>>>>> different >>>>>>>>>>>>>>>> from the users browser/os is a non common approach. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And >>>>> >>>>>> eventually >>>>>>>>>>> >>>>>>>>>>>> we >>>>>>>>>>>> >>>>>>>>>>>>> can >>>>>>>>>>>>>> >>>>>>>>>>>>>>> directly migrate away from it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So the proposal would be: >>>>>>>>>>>>>>>> Show the calendar UI and any timezone relevant >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> information >>>>>> >>>>>>> in >>>>>>> >>>>>>>> the >>>>>>>>> >>>>>>>>>> browser's >>>>>>>>>>>>>>>> timezone. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To resolve the issues in the invitations I would >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> suggest >>>>> >>>>>> the >>>>>>> >>>>>>>> following >>>>>>>>>>>> >>>>>>>>>>>>> changes: >>>>>>>>>>>>>>>> - When the user signs up the timezone is no more >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> editable/not >>>>>>>> >>>>>>>>> even >>>>>>>>>>> >>>>>>>>>>>> shown >>>>>>>>>>>>>> >>>>>>>>>>>>>>> maybe or read only and taken from the browser/client >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> os >>>>> >>>>>> - Everytime the user logs in the timezone field in >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> the >>>>> >>>>>> users >>>>>>> >>>>>>>> profile >>>>>>>>>>>> >>>>>>>>>>>>> is >>>>>>>>>>>>> >>>>>>>>>>>>>> updated with the current timezone of the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> browser/client >>>>> >>>>>> os. >>>>>> >>>>>>> The idea might be that we add a new entry in the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> table >>>>> >>>>>> OmTimeZone >>>>>>>>>>> >>>>>>>>>>>> whenever >>>>>>>>>>>>>>>> we detect any user with a new timezone. >>>>>>>>>>>>>>>> - Login view the Flash application will no more be >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> possible. >>>>>>> >>>>>>>> The >>>>>>>>> >>>>>>>>>> Openlaszlo application will only be used for the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> conference >>>>>> >>>>>>> room >>>>>>>>> >>>>>>>>>> itself >>>>>>>>>>>>> >>>>>>>>>>>>>> By doing that it should basically all just work fine. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But now comes the elefant :) We need a mapping between >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> iCal4J >>>>>>> >>>>>>>> timezones >>>>>>>>>>>>> >>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> java.util.Timezone. >>>>>>>>>>>>>>>> iCal4J is using net.fortuna.ical4j.model.**TimeZone and >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> we >>>>> >>>>>> only >>>>>>> >>>>>>>> have >>>>>>>>>>> >>>>>>>>>>>> java.util.TimeZones. This is the historical reason why >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> the >>>>>> >>>>>>> code >>>>>>>> >>>>>>>>> is a >>>>>>>>>>> >>>>>>>>>>>> little >>>>>>>>>>>>>>>> bit messed up with various timezone calculations and >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> fallbacks. >>>>>>>> >>>>>>>>> So it will be a major refactoring that should be >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> planned >>>>> >>>>>> and >>>>>>> >>>>>>>> broken >>>>>>>>>>> >>>>>>>>>>>> down >>>>>>>>>>>>> >>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> several phases. >>>>>>>>>>>>>>>> We will change and touch all and any kind of >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> functionality >>>>>> >>>>>>> in >>>>>>> >>>>>>>> OpenMeetings. >>>>>>>>>>>>>>>> It will require quite a bit of regression testing to >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> check >>>>>> >>>>>>> if >>>>>>> >>>>>>>> nothing >>>>>>>>>>>> >>>>>>>>>>>>> is >>>>>>>>>>>>> >>>>>>>>>>>>>> broken. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We generall said refactorings like this are not part >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> of >>>>> >>>>>> OpenMeetings >>>>>>>>>>> >>>>>>>>>>>> 3.0. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> And once we start this there is no way back. It will >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> delay >>>>>> >>>>>>> any >>>>>>>> >>>>>>>>> potential >>>>>>>>>>>>> >>>>>>>>>>>>>> release by 1 - 2 months. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What is the general opinion about this ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Sebastian Wagner >>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com> >>>>>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> WBR >>>>>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> WBR >>>>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Sebastian Wagner >>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com> >>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> WBR >>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Sebastian Wagner >>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com> >>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> WBR >>>>>>>>>> Maxim aka solomax >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> WBR >>>>>>>>> Maxim aka solomax >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sebastian Wagner >>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>> http://www.webbase-design.de >>>>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com> >>>>>>>> seba.wag...@gmail.com >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> WBR >>>>>>> Maxim aka solomax >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Sebastian Wagner >>>>>> https://twitter.com/#!/dead_**lock <https://twitter.com/#!/dead_lock> >>>>>> http://www.webbase-design.de >>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com> >>>>>> seba.wag...@gmail.com >>>>>> >>>>>> >>>>> >>>>> -- >>>>> WBR >>>>> Maxim aka solomax >>>>> >>>>> >>>> >>>> -- >>>> Sebastian Wagner >>>> https://twitter.com/#!/dead_**lock <https://twitter.com/#!/dead_lock> >>>> http://www.webbase-design.de >>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com> >>>> seba.wag...@gmail.com >>>> >>>> >>> >>> >> -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
