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? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >> >