On 31/08/05, Daniel Henninger <[EMAIL PROTECTED]> wrote: > I'm mildly concerned about the low number of clients that actually > support ad-hoc commands at this point. Still, I'll play with it and > see what happens. I'm semi-blind as to the full capabilities of ad- > hoc at this point, so a little playing will do me a lot of good. > Yea, AdHoc is pretty cool. There are pretty much no limits.
> >>> Please, oh, please, make this an automatic interface so that when > >>> you add a command, it adds it to the xmpp adhoc commands, and the web > >>> interface all in one foul swoop. > >> That's a good damn point, and one I hadn't thought of. I'll do that. > I think I may do something involving the current addCommand function > and an option to add to the web interface. The thing is that not all > commands are going to translate well to a web interface. For > example, a lot of them will be logged-in-user focused, and hence > useless from a web interface... at least in it's current state. I > would have to log the user in in some manner and ... eww. Not really > something I want to get into. So not -everything- is going to make > it into the web interface, but non-user-centric things will. (admin > centric I guess is the word I'm looking for there) > > Probably something like: > def addCommand(self, command, handler, name, webhandler=None): > How are you securing the web interface? Would it be that difficult to write a true abstraction for commands that was xmpp/http independent. Then write the xmpp and http backends to use the command framework. I don't think this is that hard, but it does require time to plan. Also this could get ported to the (twisted?) library fairly easily, and used for other transports too. I guess the xmpp framework is authorised by the jid and the fact that you trust the server, on the http side you could check that supplied legacy account name or jid, and password match the registered values. (although this means you have to have registered with a legacy account to admin the service too, unless you already have admin password functionality) -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ From [EMAIL PROTECTED] Wed Aug 31 14:20:12 2005 From: [EMAIL PROTECTED] (Daniel Henninger) Date: Wed Aug 31 14:20:14 2005 Subject: [py-transports] PyAIM/ICQ musings In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> > On 31/08/05, Daniel Henninger <[EMAIL PROTECTED]> wrote: >> I'm mildly concerned about the low number of clients that actually >> support ad-hoc commands at this point. Still, I'll play with it and >> see what happens. I'm semi-blind as to the full capabilities of ad- >> hoc at this point, so a little playing will do me a lot of good. >> > Yea, AdHoc is pretty cool. There are pretty much no limits. What clients are you aware of that support it? Psi w/patches is what I'm using. I recall someone saying Tkabber. Anything else? Also anyone aware of clients that are implementing it "in their next release" or "soon"? > >> >>> Please, oh, please, make this an automatic interface so that when >> >>> you add a command, it adds it to the xmpp adhoc commands, and the >> web >> >>> interface all in one foul swoop. >> >> That's a good damn point, and one I hadn't thought of. I'll do that. >> I think I may do something involving the current addCommand function >> and an option to add to the web interface. The thing is that not all >> commands are going to translate well to a web interface. For >> example, a lot of them will be logged-in-user focused, and hence >> useless from a web interface... at least in it's current state. I >> would have to log the user in in some manner and ... eww. Not really >> something I want to get into. So not -everything- is going to make >> it into the web interface, but non-user-centric things will. (admin >> centric I guess is the word I'm looking for there) >> >> Probably something like: >> def addCommand(self, command, handler, name, webhandler=None): >> > How are you securing the web interface? Simple username/password Basic auth interface. Does not tie into anything on the jabber side of the world. Ideally it should be SSL'd, but I haven't gotten around to investigating that. If I figure that out, I'm likely to forfeit non-SSL. > Would it be that difficult to write a true abstraction for commands > that was xmpp/http independent. Then write the xmpp and http backends > to use the command framework. I don't think this is that hard, but it > does require time to plan. Also this could get ported to the > (twisted?) library fairly easily, and used for other transports too. Time I'd rather spend on new features or bug fixes. ;) Also the web admin stuff isn't part of Twisted proper, it's part of "nevow", so it's not something that would likely to be put into Twisted core. Maaaaybe nevow, but nevow, I doubt, wants to add a potential requirement to have Twisted Words installed. It might be something that is possible to abstract, but it's not something I really want to spend my time on. Perhaps at a later date. Not all of the transports are interested in having a web admin interface anyway, so my work would only really be useful for my transports. Anyway, keep in mind that I haven't even touched adding the commands to the web interface yet. I may get to a point where I decide my only feasible option is to abtract it. But my focus here is to get some of the commands to be accessible in the web interface, not invent some new behind-the-scenes mechanisms. I imagine after the major features are complete and things have stabilized I will spend some time cleaning up code and seeing what improvements I can make to the internals here and there. =) > I guess the xmpp framework is authorised by the jid and the fact that > you trust the server, on the http side you could check that supplied > legacy account name or jid, and password match the registered values. > (although this means you have to have registered with a legacy account > to admin the service too, unless you already have admin password > functionality) But that still means I have to log the user in via the web interface, something I'm not aiming to do. If I do that, the next thing I'm going to hear is "why don't you implement a chat engine from the web interface" and at that point, what's the point of involving Jabber at all? I don't really want to get into the business of slowly implementing a web based AIM/ICQ client so I'm going to stick with non-user-centric things in the web interface. In fact, instead of having PyAIM do all of this, I'd rather see a good web based Jabber client written separately that can do ad-hoc commands and such. Then a user could simply log in via that, normal Jabber session, and do what they want. The commands I'm putting in the web interface are meant for the server admin(s) only. Daniel > > -- > - Norman Rasmussen > - Email: [EMAIL PROTECTED] > - Home page: http://norman.rasmussen.co.za/ > _______________________________________________ > py-transports mailing list > py-transports@blathersource.org > http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > > >
