Wicket have modules to auth via 3rd party services shouldn't be a problem
On Mon, Jun 3, 2013 at 9:48 PM, Alexei Fedotov <alexei.fedo...@gmail.com>wrote: > Maxim, > this don't seem a big architectural change for me, and I see no concerns. I > may be mistaken. And of course we should have a linkedin/twitter/facebook > user at some point. > > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://dataved.ru/ > +7 916 562 8095 > > > On Sun, Jun 2, 2013 at 4:30 PM, Maxim Solodovnik <solomax...@gmail.com > >wrote: > > > OK :) > > I would vote for unifing hash, but this can be postponed :) > > On Jun 2, 2013 3:26 PM, "seba.wag...@gmail.com" <seba.wag...@gmail.com> > > wrote: > > > > > Yes we might transfer the hash from the client to the server. > > > But this is really not doing anything with the hash, its just proxying > > data > > > ... for whatever reasons. It could be refactored so that the servlet > > takes > > > the hash direclty. But the business logic that calculates if the hash > is > > > valid, invalides it et cetera, this entire logic is already on Server > > side > > > in Java. I guess we can re-use that all, just the input and output of > > those > > > methods might be different for Wicket. > > > > > > Sebastian > > > > > > > > > 2013/6/2 Maxim Solodovnik <solomax...@gmail.com> > > > > > > > Currently we get hash in flash client, then pass it to server. > > > > I believe in later versions it should be changed to be handled by > > wicket > > > > (3.1+) > > > > On Jun 2, 2013 2:02 PM, "seba.wag...@gmail.com" < > seba.wag...@gmail.com > > > > > > > wrote: > > > > > > > > > Hi Maxim, > > > > > > > > > > I will try to answer your points more detailed, > > > > > But just about the Hash thing: > > > > > I think the Hash is mainly handled on server side and that logic is > > > > pretty > > > > > fine as it is. > > > > > The question is just how much of it needs to be implemented in > Wicket > > > for > > > > > the Html5 client. > > > > > > > > > > Seb > > > > > Am 02.06.2013 04:42 schrieb "Maxim Solodovnik" < > solomax...@gmail.com > > >: > > > > > > > > > > > Sorry I seems to miss the major questions :( > > > > > > > > > > > > I'm currently implementing PrivateMessages, and I need these > > changes > > > to > > > > > be > > > > > > able to implement Calendar appointment attendees more > > straightforward > > > > > way. > > > > > > I would like to avoid creating 2 types of attendees as well as > > > simplify > > > > > > work with chat messages. > > > > > > > > > > > > I'm not sure if these changes should be backported to flash > version > > > :( > > > > > > I would prefer to disable all flash functionality (except for > room) > > > > > > not sure if it is possible since we currently have login type > > > > "dashboard" > > > > > > > > > > > > I'll try to finish Calendar and Private Messages before > 2013.06.12. > > > > > > > > > > > > Current issues are: > > > > > > 1) minor: room invitation link is wrong (probably calendar link > > also > > > > > wrong) > > > > > > 2) Calendar Appointment attendees (not yet implemented) > > > > > > 3) Messages and Contacts area (currently implemented) > > > > > > 4) WYSIWYG editor for the calendar and chat (is on its way) > > > > > > > > > > > > Open questions: > > > > > > 1) should we rewrite our hashes to use HTML5 or let it be handled > > by > > > > > Flash > > > > > > until 3.1? > > > > > > ????? > > > > > > > > > > > > > > > > > > On Fri, May 31, 2013 at 7:26 PM, Maxim Solodovnik < > > > > solomax...@gmail.com > > > > > > >wrote: > > > > > > > > > > > > > Hello Sebastian, > > > > > > > > > > > > > > sorry for the late reply (been busy) > > > > > > > > > > > > > > I'm afraid UserContact entity should not be removed since > > currently > > > > it > > > > > is > > > > > > > used for implementing "in-system" messages > > > > > > > My idea was: > > > > > > > 1) add "type" to the user table > > > > > > > 2) remove copied fields from MeetingMember, ChatMessage and > later > > > > from > > > > > > > Invitations > > > > > > > > > > > > > > I currently need to implement calendar appointment attendees > list > > > and > > > > > > > improve chat messages structure > > > > > > > I'll double check backup import after these changes will be > > > > > implemented. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, May 29, 2013 at 5:03 PM, seba.wag...@gmail.com < > > > > > > > seba.wag...@gmail.com> wrote: > > > > > > > > > > > > > >> Hm, > > > > > > >> > > > > > > >> the backup should be always backwards compatible. I would > rather > > > > > prefer > > > > > > to > > > > > > >> really convert the old schema to the new one. > > > > > > >> It might be possible to include in the XML file of the export > a > > > > > version > > > > > > >> attribute. > > > > > > >> > > > > > > >> Depending on what version the XML has you can either do the > one > > > > style > > > > > of > > > > > > >> import (3.0 and later) or the other (2.x and older). > > > > > > >> From an end user perspective this change is actually internal > > and > > > > > > >> architectural. > > > > > > >> And just because of such a change having no support for an > > > > > export/import > > > > > > >> is > > > > > > >> rather drastic. > > > > > > >> And I think there should be a technical solution of solving > this > > > > > rather > > > > > > >> then removing some feature. > > > > > > >> > > > > > > >> So to sum those changes up: > > > > > > >> - Entity UserContact will be deleted and instead for each > > record > > > of > > > > > the > > > > > > >> UserContact there will be a record in the user table with > > > > type=contact > > > > > > >> - users with type=contact cannot login to the frontend > > > > > > >> - Exports from now one have not user contacts anymore and > there > > > is > > > > > some > > > > > > >> kind of mechanism to make sure that the old backups that have > > > such a > > > > > > >> record > > > > > > >> are successfully merged to the new design. > > > > > > >> > > > > > > >> (Btw: As far as I can see the Backup currently throws and > > > exceptions > > > > > > with > > > > > > >> 3.0: > > > > > > >> DEBUG 05-29 22:00:31.680 RequestCycle.java 418245 216 > > > > > > >> org.apache.wicket.request.cycle.RequestCycle > > > > > > >> [http-bio-0.0.0.0-5080-exec-4] > > > > > > >> - No suitable handler found for URL > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > BackupExport?moduleName=backup&sid=9a196aa0fc9459ffcf028fdbb5751e67&includeFileOption=no, > > > > > > >> falling back to container to process this request > > > > > > >> ) > > > > > > >> > > > > > > >> I think the entire Invitation thing should go into a second > > > > > discussion / > > > > > > >> later phase. It will be simply to complex now. And with all > the > > > > > changes > > > > > > >> planned to HTML5 the entire effort of reworking the Flash > > > > application > > > > > to > > > > > > >> this new design might be done a second time again. Cause > linking > > > the > > > > > > >> invitationHash to a user record and correctly login in that > user > > > > > > everytime > > > > > > >> is not something that can be done on Java side only. > > > > > > >> > > > > > > >> We could discuss if those changes will be incorporated in the > > > Flash > > > > > > part. > > > > > > >> Cause if we decide to do all changes only in the HTML5 > Calendar > > > and > > > > > > >> PrivateMessages ... there is no complete package of > Openmeetings > > > 3.0 > > > > > > >> unless > > > > > > >> those parts are refactored to HTML5. > > > > > > >> What is the planning for those components? Is it realistic > that > > we > > > > > will > > > > > > be > > > > > > >> able to do those changes _and_ do a HTML5 refactoring at the > > same > > > > > time? > > > > > > >> What is your motivation for doing that change now? > > > > > > >> > > > > > > >> Sebastian > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> 2013/5/29 Maxim Solodovnik <solomax...@gmail.com> > > > > > > >> > > > > > > >> > good questions :) > > > > > > >> > > > > > > > >> > Backup should be handled somehow ... (As intermediate > > solutions > > > we > > > > > can > > > > > > >> do > > > > > > >> > the following: leave old fields+getters/setters for 1-2 next > > > > > versions > > > > > > >> and > > > > > > >> > handle *contacts* creation while import, then remove it > > > completely > > > > > > with > > > > > > >> > declaring minimum import version like 3.0.0) > > > > > > >> > According to the invitations: I was thinking of the > following > > > > > process: > > > > > > >> > 1) user sending invitation (in 3.1.0 most probably) to the > > email > > > > > first > > > > > > >> time > > > > > > >> > 2) this email is searched in *users* db and not found, new > > user > > > of > > > > > > type > > > > > > >> > "contact" is created > > > > > > >> > 3) user sending invitation to the same email > > > > > > >> > 4) this email is searched in *users* db and found, user get > > > > > > autocomplete > > > > > > >> > option, no new "contact" is created, user gets the ability > to > > > add > > > > > > >> > first/lastname etc. to the contact > > > > > > >> > > > > > > > >> > > > > > > > >> > On Wed, May 29, 2013 at 3:24 PM, seba.wag...@gmail.com < > > > > > > >> > seba.wag...@gmail.com> wrote: > > > > > > >> > > > > > > > >> > > Hm, > > > > > > >> > > > > > > > > >> > > yes I think it makes sense, the user contacts could be > > really > > > a > > > > > user > > > > > > >> > record > > > > > > >> > > instead of a record in the user_contacts table. > > > > > > >> > > > > > > > > >> > > *Currently it is impossible, from my point of view, to > > create > > > > > > address > > > > > > >> > > book.* > > > > > > >> > > Well you can simply write a native SQL query that maps > those > > > > > tables > > > > > > >> and > > > > > > >> > > read the results into a generic SearchResult object. > > > > > > >> > > However, you are right, if you say that there is no way > you > > > > could > > > > > do > > > > > > >> that > > > > > > >> > > with JPQL. > > > > > > >> > > > > > > > > >> > > What exactly is affected by the change of the > user_contacts > > to > > > > > user > > > > > > >> > > records? > > > > > > >> > > Calendar and private messages? Is that all? > > > > > > >> > > Have you thought about how old backups will convert to > this > > > new > > > > > > design > > > > > > >> > > their data (I think there will be multiple ways to do > this, > > > but > > > > it > > > > > > >> might > > > > > > >> > be > > > > > > >> > > easier to design the solution if we discuss it upfront)? > > > > > > >> > > > > > > > > >> > > What other changes, apart from the user_contacts to user > > > record > > > > > are > > > > > > >> > planned > > > > > > >> > > as part of this change? > > > > > > >> > > Will a new invitation also create a new user for every > > > > invitation? > > > > > > Is > > > > > > >> > that > > > > > > >> > > user created when the invitation hash is created on when > the > > > > user > > > > > > >> enters > > > > > > >> > > the room? What happens if you send multiple invitations to > > the > > > > > same > > > > > > >> > email, > > > > > > >> > > will there be a new user for every of those invitations or > > > will > > > > > they > > > > > > >> be > > > > > > >> > > mapped to the same? > > > > > > >> > > > > > > > > >> > > Sebastian > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > 2013/5/29 Maxim Solodovnik <solomax...@gmail.com> > > > > > > >> > > > > > > > > >> > > > >> external invitee to a meeting that he creates through > > the > > > > > > >> calendar, > > > > > > >> > > you > > > > > > >> > > > >> would add a new entry to the table *users* ? > > > > > > >> > > > >> Is that right ? > > > > > > >> > > > Yes this was my idea :) > > > > > > >> > > > > > > > > > >> > > > I believe user_contacts might be necessary if we would > > like > > > to > > > > > > have > > > > > > >> > > > "request contact" feature (might be useful to see > contact > > > > > details > > > > > > >> > hidden > > > > > > >> > > by > > > > > > >> > > > default) > > > > > > >> > > > > > > > > > >> > > > >> How do you make sure that the same user is really the > > > > linked > > > > > > >> > > everywhere. > > > > > > >> > > > What I actually want is to have user_id in _ALL_ places > > > where > > > > I > > > > > > need > > > > > > >> > user > > > > > > >> > > > (for ex. Invitations, MeetingMember, ChatMessage etc.) > > > > > > >> > > > > > > > > > >> > > > >> what happens if two users add the same contact, but > one > > > > user > > > > > > >> decides > > > > > > >> > > > that > > > > > > >> > > > this contact now has another firstname > > > > > > >> > > > In case "contact" added is internal user editing of > > > > > first/lastnam > > > > > > >> will > > > > > > >> > > not > > > > > > >> > > > be available > > > > > > >> > > > In case "contact" added is external email address Every > > user > > > > > will > > > > > > >> > > actually > > > > > > >> > > > create its own record in *users* table. They will > differs > > by > > > > > pair > > > > > > >> > (email, > > > > > > >> > > > creator_id) > > > > > > >> > > > > > > > > > >> > > > >> Which user related object currently don't rely on the > > > > > user_id ? > > > > > > >> > > > at least Invitations, MeetingMember, ChatMessage. > > > > > > >> > > > > > > > > > >> > > > Additionally: > > > > > > >> > > > While creating Appointment in calendar we should choose > > > from 2 > > > > > > >> > different > > > > > > >> > > > lists. > > > > > > >> > > > Currently it is impossible, from my point of view, to > > create > > > > > > address > > > > > > >> > > book. > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > On Wed, May 29, 2013 at 1:41 PM, seba.wag...@gmail.com< > > > > > > >> > > > seba.wag...@gmail.com> wrote: > > > > > > >> > > > > > > > > > >> > > > > I see, I think I have bit of an idea of what you try > to > > > do. > > > > > > >> > > > > > > > > > > >> > > > > So actually when a user adds a new *contact* by adding > > for > > > > > > >> example an > > > > > > >> > > > > external invitee to a meeting that he creates through > > the > > > > > > >> calendar, > > > > > > >> > you > > > > > > >> > > > > would add a new entry to the table *users* ? > > > > > > >> > > > > Is that right ? > > > > > > >> > > > > So there would be no more table *user_contacts* as > every > > > > > contact > > > > > > >> is > > > > > > >> > > > > internal / a record in the user table in the future ? > > > > > > >> > > > > > > > > > > >> > > > > I think in theory the idea is right. Practically I > have > > > done > > > > > > >> > something > > > > > > >> > > > like > > > > > > >> > > > > that in other projects, the basic complexity here is > > > around > > > > > > >> > duplicates. > > > > > > >> > > > How > > > > > > >> > > > > do you make sure that the same user is really the > linked > > > > > > >> everywhere. > > > > > > >> > > > > Or what happens if two users add the same contact, but > > one > > > > > user > > > > > > >> > decides > > > > > > >> > > > > that this contact now has another firstname. If they > all > > > > > > reference > > > > > > >> > the > > > > > > >> > > > same > > > > > > >> > > > > user-record the other users that have this contact > might > > > not > > > > > > like > > > > > > >> > that > > > > > > >> > > > > change. > > > > > > >> > > > > > > > > > > >> > > > > But I am still not really sure what your changes will > > > really > > > > > > mean > > > > > > >> > > > > practically. > > > > > > >> > > > > > > > > > > >> > > > > For example what do you mean by: > > > > > > >> > > > > *"user related" objects to rely on user_id only* > > > > > > >> > > > > => Which user related object currently don't rely on > the > > > > > > user_id ? > > > > > > >> > > > > > > > > > > >> > > > > Seb > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > 2013/5/29 Maxim Solodovnik <solomax...@gmail.com> > > > > > > >> > > > > > > > > > > >> > > > > > Hello Sebastian, > > > > > > >> > > > > > > > > > > > >> > > > > > Actually adding this one field and make all "user > > > related" > > > > > > >> objects > > > > > > >> > to > > > > > > >> > > > > rely > > > > > > >> > > > > > on user_id only will do a lot. > > > > > > >> > > > > > > > > > > > >> > > > > > copy: > > > > > > >> > > > > > 1) Invitations: invitedname, invitedEMail, > omTimeZone > > > > > > >> > > > > > 2) MeetingMember: firstname, lastname, email, phone, > > > > > > omTimeZone > > > > > > >> > > > > > 3) ChatMessage: fromEmail, fromName, toEmail, toName > > > > > > >> > > > > > 4) RemoteSessionObject: all fields //most probably > > > should > > > > > not > > > > > > be > > > > > > >> > > > changed > > > > > > >> > > > > > .... maybe more > > > > > > >> > > > > > > > > > > > >> > > > > > 2) Currently there is no place to store "contacts". > > Only > > > > OM > > > > > > >> users > > > > > > >> > are > > > > > > >> > > > > > searchable. Users would like to have sort of Address > > > Book > > > > > with > > > > > > >> both > > > > > > >> > > OM > > > > > > >> > > > > > users and "externals" > > > > > > >> > > > > > > > > > > > >> > > > > > 3) I mean something like following: (currently > > > implemented > > > > > in > > > > > > >> > Gmail) > > > > > > >> > > > > > user starts typing name/email -> system proposes > > > > > > autocompletion > > > > > > >> > > > > > user selects from the list -> system draws "dragable > > > > > address" > > > > > > >> > > > > > user double-click "dragable address" -> system > allows > > > user > > > > > to > > > > > > >> > modify > > > > > > >> > > > > > fields: first/last/display name/email > > > > > > >> > > > > > > > > > > > >> > > > > > so it is not necessary to "Create contact" for the > > user, > > > > it > > > > > is > > > > > > >> > > created > > > > > > >> > > > as > > > > > > >> > > > > > soon as email address is entered and it is editable > > > inline > > > > > > >> (quick > > > > > > >> > and > > > > > > >> > > > > > easy). > > > > > > >> > > > > > > > > > > > >> > > > > > I believe all this dialogs and multistep wizards > > should > > > be > > > > > > used > > > > > > >> > only > > > > > > >> > > if > > > > > > >> > > > > > there is no way to avoid it .... > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > On Wed, May 29, 2013 at 11:19 AM, > > seba.wag...@gmail.com< > > > > > > >> > > > > > seba.wag...@gmail.com> wrote: > > > > > > >> > > > > > > > > > > > >> > > > > > > Hi Maxim, > > > > > > >> > > > > > > > > > > > > >> > > > > > > I am not sure if I do understand that proposal. > > > > > > >> > > > > > > In what sense does this affect what we currently > > have? > > > > > From > > > > > > >> what > > > > > > >> > I > > > > > > >> > > > > > > understood this is only one more additional column > > in > > > > the > > > > > > user > > > > > > >> > > table > > > > > > >> > > > > that > > > > > > >> > > > > > > does indicate how this user was created. > > > > > > >> > > > > > > > > > > > > >> > > > > > > But for instance users that enter a conference > room > > > via > > > > a > > > > > > >> > > invitations > > > > > > >> > > > > > link > > > > > > >> > > > > > > (hash method) still don't get an entry in the > users > > > > table, > > > > > > >> right? > > > > > > >> > > > > > > > > > > > > >> > > > > > > So in what sense does this affect anything that > > exists > > > > so > > > > > > far? > > > > > > >> > > > > > > > > > > > > >> > > > > > > *pros: > > > > > > >> > > > > > > 1) everything working with "user" can rely on > > user_id > > > > > only, > > > > > > no > > > > > > >> > need > > > > > > >> > > > to > > > > > > >> > > > > > copy > > > > > > >> > > > > > > any data fields * > > > > > > >> > > > > > > => Where do we currently copy any fields ? > > > > > > >> > > > > > > > > > > > > >> > > > > > > *2) all fields requires entering of user can be > > > enhanced > > > > > > with > > > > > > >> > > > > > autocomplete > > > > > > >> > > > > > > and inline edit (so user can enter as much info as > > > > he/she > > > > > is > > > > > > >> > ready > > > > > > >> > > at > > > > > > >> > > > > the > > > > > > >> > > > > > > moment)* > > > > > > >> > > > > > > => What prevents you from doing this currently ? > > > > > > >> > > > > > > > > > > > > >> > > > > > > *3) add/edit user of type contact anytime user > > enters > > > > > email > > > > > > >> > > > > > not-registered > > > > > > >> > > > > > > in the system* > > > > > > >> > > > > > > => Sorry I don't understand this at all. A user of > > > type > > > > > > >> contact > > > > > > >> > ... > > > > > > >> > > > how > > > > > > >> > > > > > is > > > > > > >> > > > > > > that user to be logged in in at all? In your > > > description > > > > > you > > > > > > >> > write > > > > > > >> > > > that > > > > > > >> > > > > > > only users of type "user" can login. > > > > > > >> > > > > > > > > > > > > >> > > > > > > Thanks, > > > > > > >> > > > > > > Sebastian > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > 2013/5/29 Maxim Solodovnik <solomax...@gmail.com> > > > > > > >> > > > > > > > > > > > > >> > > > > > > > Hello All, > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > I would like to propose to change the way OM > works > > > > with > > > > > > >> users. > > > > > > >> > > > > > > > Currently we have 3 entities acts like "User": > > > > > > >> > > > > > > > 1) OM user (the entity created using OM Admin) > > > > > > >> > > > > > > > 2) External user (the entity created via > SOAP/REST > > > > call, > > > > > > >> > actually > > > > > > >> > > > it > > > > > > >> > > > > is > > > > > > >> > > > > > > > normal user with externalType/externalId set) > > > > > > >> > > > > > > > 3) "hash" user ("something" created while > sending > > > > > > invitation > > > > > > >> > hash > > > > > > >> > > > or > > > > > > >> > > > > > > > inviting external user via calendar) > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > What I would like to propose: > > > > > > >> > > > > > > > 1) add `type` column to the User table (see [1]) > > > > > > >> > > > > > > > 2) allow front-end login for *type == user* only > > > (ldap > > > > > > users > > > > > > >> > will > > > > > > >> > > > be > > > > > > >> > > > > > > > allowed to login only id LDAP is selected) > > > > > > >> > > > > > > > 3) add/edit user of type contact anytime user > > enters > > > > > email > > > > > > >> > > > > > not-registered > > > > > > >> > > > > > > > in the system > > > > > > >> > > > > > > > 4) add user created to one of the groups of the > > user > > > > > > created > > > > > > >> > this > > > > > > >> > > > > > contact > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > pros: > > > > > > >> > > > > > > > 1) everything working with "user" can rely on > > > user_id > > > > > > only, > > > > > > >> no > > > > > > >> > > need > > > > > > >> > > > > to > > > > > > >> > > > > > > copy > > > > > > >> > > > > > > > any data fields > > > > > > >> > > > > > > > 2) all fields requires entering of user can be > > > > enhanced > > > > > > with > > > > > > >> > > > > > autocomplete > > > > > > >> > > > > > > > and inline edit (so user can enter as much info > as > > > > > he/she > > > > > > is > > > > > > >> > > ready > > > > > > >> > > > at > > > > > > >> > > > > > the > > > > > > >> > > > > > > > moment) > > > > > > >> > > > > > > > 3) drag-n-drop should be added to various OM > > > > components > > > > > to > > > > > > >> be > > > > > > >> > > able > > > > > > >> > > > to > > > > > > >> > > > > > > > implement address book > > > > > > >> > > > > > > > 4) Single component acting as address book can > > > easily > > > > be > > > > > > >> added > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > cons: > > > > > > >> > > > > > > > 1) to avoid naming conflicts and personal > contact > > > > lists > > > > > > >> sharing > > > > > > >> > > > > > > > searching/autocompleting of the contacts should > be > > > > done > > > > > > with > > > > > > >> > > strict > > > > > > >> > > > > > > > filtering by creator/owner id > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > [1] enum Type { > > > > > > >> > > > > > > > user > > > > > > >> > > > > > > > , ldap //should we add it??? > > > > > > >> > > > > > > > , external > > > > > > >> > > > > > > > , contact > > > > > > >> > > > > > > > } > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > Please let me know if you have any concerns > > > regarding > > > > > this > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > -- > > > > > > >> > > > > > > > WBR > > > > > > >> > > > > > > > Maxim aka solomax > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > -- > > > > > > >> > > > > > > Sebastian Wagner > > > > > > >> > > > > > > https://twitter.com/#!/dead_lock > > > > > > >> > > > > > > http://www.webbase-design.de > > > > > > >> > > > > > > http://www.wagner-sebastian.com > > > > > > >> > > > > > > seba.wag...@gmail.com > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > -- > > > > > > >> > > > > > WBR > > > > > > >> > > > > > Maxim aka solomax > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > -- > > > > > > >> > > > > Sebastian Wagner > > > > > > >> > > > > https://twitter.com/#!/dead_lock > > > > > > >> > > > > http://www.webbase-design.de > > > > > > >> > > > > http://www.wagner-sebastian.com > > > > > > >> > > > > seba.wag...@gmail.com > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > -- > > > > > > >> > > > WBR > > > > > > >> > > > Maxim aka solomax > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > -- > > > > > > >> > > Sebastian Wagner > > > > > > >> > > https://twitter.com/#!/dead_lock > > > > > > >> > > http://www.webbase-design.de > > > > > > >> > > http://www.wagner-sebastian.com > > > > > > >> > > seba.wag...@gmail.com > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > -- > > > > > > >> > WBR > > > > > > >> > Maxim aka solomax > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> -- > > > > > > >> Sebastian Wagner > > > > > > >> https://twitter.com/#!/dead_lock > > > > > > >> http://www.webbase-design.de > > > > > > >> http://www.wagner-sebastian.com > > > > > > >> seba.wag...@gmail.com > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > WBR > > > > > > > Maxim aka solomax > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > WBR > > > > > > Maxim aka solomax > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Sebastian Wagner > > > https://twitter.com/#!/dead_lock > > > http://www.webbase-design.de > > > http://www.wagner-sebastian.com > > > seba.wag...@gmail.com > > > > > > -- WBR Maxim aka solomax