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
>
