Ely Celino wrote:
> Yes I know it is not ready for production yet. But I am researching on way
> to re-implement my system. If Vysper works, then I will use it after it is
> released. Right now, I am trying to fit Vysper to my requirements. I am just
> hoping that I am able to help the project by doing this.
> 
> Cheers!

Everything helps, from asking questions or reporting bugs to providing
patches!

  Bernd

> 
> On Tue, Sep 8, 2009 at 3:53 PM, Bernd Fondermann <bf_...@brainlounge.de>wrote:
> 
>> Ely Celino wrote:
>>> Right now, there are 28.
>> Disclaimer: In my opinion, Vysper is not yet ready for production.
>> If it works for your use case, I'm happy and proud though. :-)
>>
>>  Bernd
>>
>>> On Tue, Sep 8, 2009 at 6:55 AM, Fernando Padilla <f...@alum.mit.edu>
>> wrote:
>>>> by the way, how many "clients" do you have to support?  Would it be
>> crazy
>>>> to simply run a unique vysper server for now?
>>>>
>>>>
>>>> On 9/7/09 3:43 AM, Ely Celino wrote:
>>>>
>>>>> Thank you guys for the help. You're right Fernando, usernames in my db
>> are
>>>>> unique per client and may be duplicated across my whole db. Yes it is
>>>>> cleaner to give each client their own domain name but as Bernd already
>>>>> have
>>>>> said, It would require substantial refactorings.
>>>>>
>>>>> Google I think is using the concept of subdomains for Google talk
>> (which
>>>>> we
>>>>> know is using xmpp). My company is using Google apps and gave me an
>>>>> account
>>>>> under it (e...@mycompany.com). I am able to use this account in Pidgin,
>> my
>>>>> server is talk.google.com but my domain is mycompany.com.
>>>>>
>>>>> My apology to Bernd, I did not know that resource is assigned after
>>>>> authentication. I think I have to read more of xmpp documentations
>> rather
>>>>> than jumping to conclusions and get excited.
>>>>>
>>>>>
>>>>> On Mon, Sep 7, 2009 at 12:23 AM, Fernando Padilla<f...@alum.mit.edu>
>>>>>  wrote:
>>>>>
>>>>>
>>>>>
>>>>>> So basically it sounds like Ely has different groups of users with
>>>>>> possibly
>>>>>> overlapping usernames?
>>>>>>
>>>>>> fern(from citizensports)
>>>>>> fern(from othercompany)
>>>>>>
>>>>>> So the JIDs need to be unique per users?
>>>>>>
>>>>>> But the resource part of the JID is only there to identify a
>> particular
>>>>>> connection to the server, not the actual user ( as Bernd said, only
>> after
>>>>>> authentication does resources ids get worked out ).
>>>>>>
>>>>>> So you can only put it in the username or in a subdomain:
>>>>>>
>>>>>> fern_citizenspo...@domain.com
>>>>>> fern_othercomp...@domain.com
>>>>>>
>>>>>> or in the subdomain:
>>>>>>
>>>>>> f...@citizensports.domain.com
>>>>>> f...@othercompany.domain.com
>>>>>>
>>>>>> which seems much cleaner and nicer to me, but vysper can't support
>> this
>>>>>> at
>>>>>> the moment :(
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/5/09 4:29 AM, Bernd Fondermann wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi Ely,
>>>>>>>
>>>>>>> thanks for following up. I think I still don't totally understand
>> what
>>>>>>> you want to do. Next try...
>>>>>>>
>>>>>>> Ely Celino wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Well, it would be nice if we could have something like
>>>>>>>> myXmppServer.addDomain("anotherdomain.com").
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Sure, but this would require substantial refactorings.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> But, if it would mess things up
>>>>>>>> I would just put out registration out of xmpp protocol.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> If you use a plain vanilla vysper from SVN, there is no possibility
>> of
>>>>>>> account registration of users yet using the XMPP protocol. Neither
>>>>>>> in-band registration (XEP-0077) nor using service administration
>>>>>>> (XEP-0133, XEP-0050). AccountManagement is only accessible within the
>>>>>>> JVM, not via XMPP.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Then, I would sign
>>>>>>>> in account using usern...@mydomain.com/clientid.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Why would you do that? What does that help? XMPP only assigns
>> resources
>>>>>>> (what you depict as "/clientid" here) _after_ authentication.
>>>>>>>
>>>>>>> Are you talking here about your own heavily customized version of
>>>>>>> Vysper?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I believe it is possible to
>>>>>>>> specify the resource to be used upon authentication.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> + Resource registration is only possible after authentication
>>>>>>> + Accepting the resource id from the client is OPTIONAL for the
>> server
>>>>>>> + Vysper does not accept a client's resource id.
>>>>>>>
>>>>>>> I'm not completely understanding your goal yet, I guess.
>>>>>>>
>>>>>>>   Bernd
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Sat, Sep 5, 2009 at 2:25 PM, Bernd Fondermann<
>> bf_...@brainlounge.de
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Fernando Padilla wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> username is JID.
>>>>>>>>>>
>>>>>>>>>> JID is n...@domain
>>>>>>>>>>
>>>>>>>>>> you don't want to embed the clientid on the domain?
>>>>>>>>>>
>>>>>>>>>> usern...@clientid.domain
>>>>>>>>>>
>>>>>>>>>> so as long as vysper will recognize all of the sub-domains
>> properly
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> it wouldn't, as far as I can tell.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> (anyone want to comment on having vysper server deal with many
>>>>>>>>>> sub-domains? or virtual hosts?)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> you would need to have more than one ServerRuntimeContext (SRC),
>> each
>>>>>>>>> serving one domain and write a clever MINABasedSessionContext which
>> is
>>>>>>>>> able to route to the right SRC.
>>>>>>>>>
>>>>>>>>> Having one SRC for more than one Domain requires significant
>>>>>>>>> refactorings (hint: SRC.getServerEntity())
>>>>>>>>>
>>>>>>>>> Patches, as always, are welcome.
>>>>>>>>>
>>>>>>>>>  Bernd
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 9/3/09 11:58 PM, Ely Celino wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>
>>>>>>>>>>> After implementing AccountManagement, I realized I need other
>> data
>>>>>>>>>>> other
>>>>>>>>>>> than user and password in addUser(user, password) function.
>>>>>>>>>>>
>>>>>>>>>>> My user db consolidates all my client's record. To distinguish
>> every
>>>>>>>>>>> client
>>>>>>>>>>> I added client_id column. So if query for a user, I will search
>> by
>>>>>>>>>>> username
>>>>>>>>>>> plus client_id.
>>>>>>>>>>>
>>>>>>>>>>> Of course I could use the username parameter to the addUser
>> function
>>>>>>>>>>> by
>>>>>>>>>>> concataning other information to it but we know it will be ugly.
>>>>>>>>>>>
>>>>>>>>>>> Is this a limitation of the AccountManagement?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>
> 

Reply via email to