xmpppy-devel — Main place to discuss problems request features and to get support.

Re: [Xmpppy-devel] Upcoming major changes

[Alexey N. <sn...@pe...>]

=F7 =D3=CF=CF=C2=DD=C5=CE=C9=C9 =CF=D4 =F7=D4=CF=D2=CE=C9=CB 04 =F1=CE=D7=
=C1=D2=D8 2005 22:40 mik...@yu...=20
=CE=C1=D0=C9=D3=C1=CC(a):
> Alexey,
>
> I hope that you will be supplying a mechanism to return or find the raw
> socket object so that it can be used within an external select or poll.
> This will cause problems when trying to manage a lot of connections or
> cleanly integrating with a GUI. If not, how do you expect these cases to =
be
> handled?
These changes are targeted to itegrate poll() into the library and remove=20
select() calls (to allow override 1024 user barrier) so the requested=20
interface will definitely be provided.

> On Tue, Jan 04, 2005 at 10:00:55PM +0300, Alexey Nezhdanov wrote:
> > I'm now re-working some internal data representation in xmpppy library.
> > The most visible changes will be (1) inaccessibility (in the old way) of
> > transport classes and (2) total transition from using Client class as
> > container to using Session class as container.
> >
> > I.e.
> > 1) you will not be able to access tcp/ssl socket directly:
> > client.TCPsocket reference will not work anymore
> >
> > 2) if you will need to access some sesion parameters that were stored in
> > client instance you should use session class instance instead.
> >
> > Though I suppose that for most projects the changes should be completely
> > transparent or in the failure case just the search and replace job.
> >
> > This will be the last serious changes in the 0.2 branch.

=2D-=20
Respectfully
Alexey Nezhdanov

Re: [Xmpppy-devel] Upcoming major changes

[<mik...@yu...>]

Alexey,

I hope that you will be supplying a mechanism to return or find the raw socket object so that it can be used within an external select or poll. This will cause problems when trying to
manage a lot of connections or cleanly integrating with a GUI. If not, how do you expect these cases to be handled?

Thanks

Mike


On Tue, Jan 04, 2005 at 10:00:55PM +0300, Alexey Nezhdanov wrote:
> I'm now re-working some internal data representation in xmpppy library.
> The most visible changes will be (1) inaccessibility (in the old way) of 
> transport classes and (2) total transition from using Client class as 
> container to using Session class as container.
> 
> I.e.
> 1) you will not be able to access tcp/ssl socket directly:
> client.TCPsocket reference will not work anymore
> 
> 2) if you will need to access some sesion parameters that were stored in 
> client instance you should use session class instance instead.
> 
> Though I suppose that for most projects the changes should be completely 
> transparent or in the failure case just the search and replace job.
> 
> This will be the last serious changes in the 0.2 branch.
> 
> -- 
> Respectfully
> Alexey Nezhdanov
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Xmpppy-devel mailing list
> Xmp...@li...
> https://lists.sourceforge.net/lists/listinfo/xmpppy-devel
> 

[Xmpppy-devel] Upcoming major changes

[Alexey N. <sn...@pe...>]

I'm now re-working some internal data representation in xmpppy library.
The most visible changes will be (1) inaccessibility (in the old way) of 
transport classes and (2) total transition from using Client class as 
container to using Session class as container.

I.e.
1) you will not be able to access tcp/ssl socket directly:
client.TCPsocket reference will not work anymore

2) if you will need to access some sesion parameters that were stored in 
client instance you should use session class instance instead.

Though I suppose that for most projects the changes should be completely 
transparent or in the failure case just the search and replace job.

This will be the last serious changes in the 0.2 branch.

-- 
Respectfully
Alexey Nezhdanov

[Xmpppy-devel] Fwd: Re: XMPPPY Development

[Alexey N. <sn...@pe...>]

Resending reply to maillist since I think that it is worths it.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=F7 =D3=CF=CF=C2=DD=C5=CE=C9=C9 =CF=D4 =F3=D5=C2=C2=CF=D4=C1 01 =F1=CE=D7=
=C1=D2=D8 2005 08:47 Brian Almond =CE=C1=D0=C9=D3=C1=CC(a):
> Alexey,
>
> Recently I've gotten very interested in Jabber/XMPP, both from the
> server & client side.  I've been reading the XMPP RFCs, and have been
> looking at doing some development using Python.  This interest led me
> to your xmpppy project on sourceforge.  Great stuff!
thanks :)

> I'm going start looking through the project code and trying out bits
> of it.  Are there any areas you need help with on the project, where a
> relative newcomer to XMPP (but fairly experienced Python programmer)
> like myself could be useful to you?
My expirience shows that all shortcomings of library is coming on the light=
=20
when I'm beginning to use it. So I have no any specific ideas of what shoul=
d=20
be done first. Fell free to imagine it yourself.

> Also, do you have a "roadmap" online which indicates the direction
> your project is taking and what goals you have set?
The roadmap is absent in any written form but it exists in very uncertain=20
state in my mind :)
It is something like this:
0.1 support of all that jabberpy project can (already done)
0.2 document library (Documentation should be proof-read though. Many thing=
s=20
should be evaluated more verbously). Plus 0.2 release will have "Session"=20
class usage, ported from xmppd.py project (underway).
0.3 Do not clear yet. I'm thinking about adding native python xml library l=
ike=20
libxml2 as a backend. This will change only simplexml.py module though.

Probably after 0.2 release I'll resume xmppd.py project so the main feature=
s=20
that will go into library will be 'Draft JEP's support.

> Thanks for your time.  I hope I can contribute something of value to
> the project after I gain some experience with it.
You are welcome.

> -Brian

=2D-=20
Respectfully
Alexey Nezhdanov

Re: [Xmpppy-devel] some api documentation

[Alexey N. <sn...@pe...>]

=F7 =D3=CF=CF=C2=DD=C5=CE=C9=C9 =CF=D4 =FE=C5=D4=D7=C5=D2=C7 23 =E4=C5=CB=
=C1=C2=D2=D8 2004 23:39 Alexey Nezhdanov =CE=C1=D0=C9=D3=C1=CC(a):
> I have merged initial docstrings for modules --init--, simplexml, auth,
> client, dispatcher.
> epydoc-produced pages published here:
> http://xmpppy.sf.net/apidocs/
Just made a CVS checking with the docstrings for all remaining undocumented=
=20
modules.
=46rom now on I will maintain and improve these docstrings to keep xmpppy f=
ully=20
and up-to-date documented.

=2D-=20
Respectfully
Alexey Nezhdanov

Re: [Xmpppy-devel] async events

[<lui...@ne...>]

On Dec 25, 2004, at 5:19 AM, Alexey Nezhdanov wrote:

> I do not see the point in interrupting Process(). You can call it w/o
> arguments and it will return ASAP w/o any waiting so you will not 
> waste any
> time and will not waste much resources since if there are no pending 
> events
> the work of the Process() will be only calling select() on your tcp 
> socket.

Yes, but if you are calling Process in a cycle and it returns 
immediately then you'll be calling it constantly. In that case it won't 
matter how inexpensive Process() is since your task won't block and 
will thus consume all the available CPU time in its infinite loop.

I can't see how it cannot be so: if Process() isn't running then it's 
not serving xmpp events; if it is running blocked waiting for a xmppy 
event then it won't service any external events; if it runs but doesn't 
block it will have to be called uninterruptedly, which works but keeps 
consuming resources even in the absence of any type of events.

> At present I use poll() in my xmppd.py project instead of select() in 
> xmpppy.
> I'm planning to port this functionality into the xmpppy so it will be 
> possible
> to register additional "interrupt" file object. For now you can do:
> #============================
> class MyDispatcher(xmpp.dispatcher.Dispatcher):
>  def Process(timeout=0):
>   pass
>   # do something more handy
> xmpp.dispatcher.Dispatcher=MyDispatcher
> # ...
> cl=xmpp.Client('some.jabber.host')
> #...
> #============================

That's very nice :) I'll see what I can do but I'm not very worried 
ATM. I'm developing a prototype so even if it keeps running without 
block its not of much concern for now.

Re: [Xmpppy-devel] async events

[Alexey N. <sn...@pe...>]

=D0=92 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B8 =D0=BE=D1=82 =
=D0=A1=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0 25 =D0=94=D0=B5=D0=BA=D0=B0=D0=
=B1=D1=80=D1=8C 2004 05:58 Lu=C3=ADs Marques =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0=D0=BB(a):
> Hello,
>
> The current support for asynchronous events seems to be lacking. There
> is no mechanism to allow waiting for both xmppy and external events.
> For instance, if you have a GUI that might, at some arbitrary point in
> time, send a message then you have to specify a low timeout in
> client.Process(), so that you can keep checking for xmppy events and
> GUI events. There needs to be a way of interrupting Process(). Using a
> low timeout is a waste of system resources and making the timeout
> bigger will result in latency processing external requests.
I do not see the point in interrupting Process(). You can call it w/o=20
arguments and it will return ASAP w/o any waiting so you will not waste any=
=20
time and will not waste much resources since if there are no pending events=
=20
the work of the Process() will be only calling select() on your tcp socket.

> How about something like specifying a file descriptor (or something
> more Pythonic) in Process(), that will interrupt the waiting when data
> is available?
At present I use poll() in my xmppd.py project instead of select() in xmppp=
y.
I'm planning to port this functionality into the xmpppy so it will be possi=
ble=20
to register additional "interrupt" file object. For now you can do:
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
class MyDispatcher(xmpp.dispatcher.Dispatcher):
 def Process(timeout=3D0):
  pass
  # do something more handy
xmpp.dispatcher.Dispatcher=3DMyDispatcher
# ...
cl=3Dxmpp.Client('some.jabber.host')
#...
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

> That needs to be addressed, if more than reactive clients are to be
> built.
> Thanks. Merry Xmas :)
>
> --
> Lu=C3=ADs Marques

=2D-=20
Respectfully
Alexey Nezhdanov

[Xmpppy-devel] async events

[<lui...@ne...>]

Hello,

The current support for asynchronous events seems to be lacking. There=20=

is no mechanism to allow waiting for both xmppy and external events.=20
For instance, if you have a GUI that might, at some arbitrary point in=20=

time, send a message then you have to specify a low timeout in=20
client.Process(), so that you can keep checking for xmppy events and=20
GUI events. There needs to be a way of interrupting Process(). Using a=20=

low timeout is a waste of system resources and making the timeout=20
bigger will result in latency processing external requests.

How about something like specifying a file descriptor (or something=20
more Pythonic) in Process(), that will interrupt the waiting when data=20=

is available?

That needs to be addressed, if more than reactive clients are to be=20
built.
Thanks. Merry Xmas :)

--
Lu=EDs Marques=

[Xmpppy-devel] some api documentation

[Alexey N. <sn...@us...>]

I have merged initial docstrings for modules --init--, simplexml, auth, 
client, dispatcher.
epydoc-produced pages published here:
http://xmpppy.sf.net/apidocs/

-- 
Respectfully
Alexey Nezhdanov

[Xmpppy-devel] Re: CVS or released version?

[Peter Saint-A. <st...@ja...>]

In article <200...@pe...>,
 Alexey Nezhdanov <sn...@pe...> wrote:

> ÷ ÓÏÏÂÝÅÎÉÉ ÏÔ ðÑÔÎÉÃÁ 17 äÅËÁÂÒØ 2004 08:18 Alexey Nezhdanov ÎÁÐÉÓÁÌ(a):
> > ÷ ÓÏÏÂÝÅÎÉÉ ÏÔ ðÑÔÎÉÃÁ 17 äÅËÁÂÒØ 2004 03:54 Peter Saint-Andre ÎÁÐÉÓÁÌ(a):
> > > I need to write a new bot and I'm thinking of using xmpppy (my existing
> > > bots are written on top of jabber.py, and I may update them, too). Is
> > > CVS quite different from xmpppy 0.2-pre1? Will the API be changing much?
> >
> > I'm consider 0.1 version as "stable" and 0.2 is current development branch.
> > <snip/>
> Too much words w/o specific answer. Sorry.
> Current CVS differs from 0.2-pre1 only by bugfixes. I'm not planning to 
> change 
> API much in 0.2 branch.

OK, thanks for the information. After chatting with Mike, I think I'll 
go with 0.2cvs and feed in any bug reports that I find.

Peter

Re: [Xmpppy-devel] CVS or released version?

[Mike A. <mi...@yu...>]

Peter,

I would go with CVS, or the 0.2-pre1. 0.1 was good, but anything after that had quite a few fixes to make it a lot more stable for the things I use it for. Also there are some differences
in the API between those versions. One main advantage of the CVS is the browser.py Browser class works, which takes care of service discovery hosting. I am currently working on a Jep-0050
plugin to that class so Ad-Hoc commands are easy to implement.


The main problem with CVS recently was that auth broke, but Alexey debugged and fixed that quite quickly.

If you have any problems, you can bug me, instead of the other way round.

Mike



On Thu, Dec 16, 2004 at 05:54:30PM -0700, Peter Saint-Andre wrote:
> I need to write a new bot and I'm thinking of using xmpppy (my existing 
> bots are written on top of jabber.py, and I may update them, too). Is 
> CVS quite different from xmpppy 0.2-pre1? Will the API be changing much?
> 
> Thanks!
> 
> Peter
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Xmpppy-devel mailing list
> Xmp...@li...
> https://lists.sourceforge.net/lists/listinfo/xmpppy-devel
> 

Re: [Xmpppy-devel] CVS or released version?

[Alexey N. <sn...@pe...>]

=F7 =D3=CF=CF=C2=DD=C5=CE=C9=C9 =CF=D4 =F0=D1=D4=CE=C9=C3=C1 17 =E4=C5=CB=
=C1=C2=D2=D8 2004 08:18 Alexey Nezhdanov =CE=C1=D0=C9=D3=C1=CC(a):
> =F7 =D3=CF=CF=C2=DD=C5=CE=C9=C9 =CF=D4 =F0=D1=D4=CE=C9=C3=C1 17 =E4=C5=CB=
=C1=C2=D2=D8 2004 03:54 Peter Saint-Andre =CE=C1=D0=C9=D3=C1=CC(a):
> > I need to write a new bot and I'm thinking of using xmpppy (my existing
> > bots are written on top of jabber.py, and I may update them, too). Is
> > CVS quite different from xmpppy 0.2-pre1? Will the API be changing much?
>
> I'm consider 0.1 version as "stable" and 0.2 is current development branc=
h.
> <snip/>
Too much words w/o specific answer. Sorry.
Current CVS differs from 0.2-pre1 only by bugfixes. I'm not planning to cha=
nge=20
API much in 0.2 branch.

=2D-=20
Respectfully
Alexey Nezhdanov

Re: [Xmpppy-devel] CVS or released version?

[Alexey N. <sn...@pe...>]

=F7 =D3=CF=CF=C2=DD=C5=CE=C9=C9 =CF=D4 =F0=D1=D4=CE=C9=C3=C1 17 =E4=C5=CB=
=C1=C2=D2=D8 2004 03:54 Peter Saint-Andre =CE=C1=D0=C9=D3=C1=CC(a):
> I need to write a new bot and I'm thinking of using xmpppy (my existing
> bots are written on top of jabber.py, and I may update them, too). Is
> CVS quite different from xmpppy 0.2-pre1? Will the API be changing much?
I'm consider 0.1 version as "stable" and 0.2 is current development branch.

0.2 have quite a few differences from 0.1 API, mainly in dispatcher module.=
=20
And also 0.2 is considerable less stable (Mike Albon can stand it I=20
think :) ). The main differences is support of namespaces in handlers and=20
support of "Session" class that contains all session info instead of "Clien=
t"=20
class that were used for such purposes in 0.1.
So you can have a single Client class instance with a set of Session instan=
ces=20
=2D one for each connection.

The only reason for this was development of xmppd.py wich is suspended now=
=20
unfortunately :(

So you have two options:
1) use 0.1 and have fun
2) use 0.2 and bug me about any bug that you encounter. Mike went this rout=
e=20
and I hope that he was not disappoined. I'll help you with any issue ASAP.

Personally I recommend second way - for my personal reasons - this will hel=
p=20
shake out bugs and release 0.2-stable.

=2D-=20
Respectfully
Alexey Nezhdanov

[Xmpppy-devel] CVS or released version?

[Peter Saint-A. <st...@ja...>]

I need to write a new bot and I'm thinking of using xmpppy (my existing 
bots are written on top of jabber.py, and I may update them, too). Is 
CVS quite different from xmpppy 0.2-pre1? Will the API be changing much?

Thanks!

Peter

[Xmpppy-devel] Message/Presence/Iq Handlers

[Charles J. <cjo...@gm...>]

I know it doesn't exist, so you might consider this a feature request.
 It would be very handy if one could set a handler to be called when
stanzas arrive from just a specific JID.  IE, something like...

jabber.RegisterHandler('message', JID('us...@se...'), message_cb)
   -or-
jabber.RegisterHandler('message', JID('us...@se.../resource'), message_cb)

do you think something like that would reasonably fit into xmpppy?

-- 
Charles Josephs

[Xmpppy-devel] xmppd.py 0.2 released, xmpppy 0.2-pre1 released

[Alexey N. <sn...@pe...>]

I have just released 0.2 version of xmpppd.py - the XMPP protocol server 
written in python.

The server is still barebones but I'm already planning to begin use it in 
semi-production conditions.

Changes since 0.1 (PoC) release:
1) Almost full XMPP Core compliance. The lacks:
 a) S2S SASL auth absent. Will be done via EXTERNAL mechanism.
        b) JID format checking absent.
2) S2S dialback support.

=======================================================
Along with server the backend xmpppy library 0.2-pre1 release is made. It is a 
simple snapshot from xmppd0.2 release and contains various tweaks that were 
needed for xmppd work:

DISCO server framework
Changes in SASL credentials passing ("auth" method introduced)
(MAIN) Dispatcher changes. Now it is stream namespace-aware. You can register 
default handler for each used namespace.
Chain handlers removed.
Several additional namespaces added.
SASL error conditions added
(IMPORTANT) JID node and JID domain now stored in lowercase!
simplexml now allows dictionary reference to attributes (f.e. stanza['to'])
simplexml now allows attribute reference to sub-nodes (f.e. iq.T.query)
protocol elements now return JID objects for 'to' and 'from' attributes
DataForm class replaced with new implementation (that is in turn using 
DataField class)

-- 
Respectfully
Alexey Nezhdanov

[Xmpppy-devel] Re: xmppd last commit

[Peter Saint-A. <st...@ja...>]

In article <200...@pe...>,
 Alexey Nezhdanov <sn...@pe...> wrote:

> Hello.
> I've just checked in the changes that were resided in my private repository.
> There only a few changes since the main thing that were eating my time was 
> thorough reading of xmpp-core document.
> Expect rapid bugfixing, s2s functionality addition and 0.2 release in the 
> nearest two weeks.

Good work, Alexey! ;-)

/psa

[Xmpppy-devel] xmppd last commit

[Alexey N. <sn...@pe...>]

Hello.
I've just checked in the changes that were resided in my private repository.
There only a few changes since the main thing that were eating my time was 
thorough reading of xmpp-core document.
Expect rapid bugfixing, s2s functionality addition and 0.2 release in the 
nearest two weeks.
-- 
Respectfully
Alexey Nezhdanov

Re: [Xmpppy-devel] code comprehension

[Alexey N. <sn...@pe...>]

=F7 =D3=CF=CF=C2=DD=C5=CE=C9=C9 =CF=D4 =FE=C5=D4=D7=C5=D2=C7 30 =F3=C5=CE=
=D4=D1=C2=D2=D8 2004 22:25 oboe =CE=C1=D0=C9=D3=C1=CC(a):
> On Thu, Sep 30, 2004 at 08:14:19AM +0400, Alexey Nezhdanov wrote:
> > > > Probably you are using xmppd.py with old xmpppy library. Try using
> > > > version, included in xmppd.tar.gz package.
> > >
> > > Actually, I'm making the assumption that cvs mainline is :basically:
> > > functional code.
> >
> > My main CVS repository resides on my hard disk because of too slow
> > channel to SF from my home (actually a very busy 9600bps link). So SF's
> > CVS check ins are rare now and xmppd.py and xmpppy reposytoryes are
> > out-of-sync sometimes. The nxvoc feature was added to xmpppy code just
> > before xmppd-0.1 release and then I've considered it harmful and removed
> > it.
>
> So this means your dev code is on your local machine (jeez, make
> backups!)and at stable points you commit up to the SF cvs server?
More precise - at the certaint points of mood state. If there is no hurry -=
=20
the check in performed. If I'm just stating some point of development and=20
going to continue coding now - the checkin is not performed. The latter can=
=20
also happen if it is too late and I'm going to sleep.

> I'll grab a tarball for now and play with it. A CHANGES or NOTES file mig=
ht
> be of some help, if you can note which features you add as you go, and
> checkout cvs to make tarballs.
I'm trying to make detailed comments on CVS checkins so try "cvs log".

=2D-=20
Respectfully
Alexey Nezhdanov

Re: [Xmpppy-devel] code comprehension

[<mik...@yu...>]

Hi,

I don't see what advantage moving to jabberstudio gives? Can you expand what the advantages are?

As to the sematics in style, all the code looks ok to me in the SF cvs under the xmppd directory. There again I am used to the style used by Alexey now. 

Certainly from my perspective what would be useful is a hint on what should be documented and not how.

Indeed you are right about documentation, and as it concerns you, does that offer of help extend to helping get the documentation in order for the prior art? (*cheeky grin*)

TTFN

Mike

Re: [Xmpppy-devel] code comprehension

[oboe <ob...@en...>]

On Thu, Sep 30, 2004 at 08:14:19AM +0400, Alexey Nezhdanov wrote:
> > > > > confusing code.
> > I still stand by my statement (:
> > Since you write no documentation, can you at least add a couple simple
> > comments as you go? I'd like to help, but your code is not the :most: self
> > explanitory. Python is not my first language.
> I have nothing to complain. The xmppd.py project targets for several goals and 
> "well-documented" is among them. I'll try to start acheving it.
> 
I see that someone has brought this up in the past, I dont want to be a pain and just complain more. (: I'm more than interested in helping where I can, at the moment, my understanding of your code isnt knowledgable enough to be of any aid.

I would encourage you to take a look at strogge's "newsbot" project on JabberStudio (http://jabberstudio.org/projects/newsbot/project/view.php). Also, you might consider putting xmpp/xmppd on Temas' JabberStudio site rather than SF.

Strogge manages to use a combination of insightful comments, at a minimum, along with well chosen object/variable/function names. The code is fairly self documenting that way. I understand you prefer tight code, but one letter variable names are counterproductive for future readability. (:

I am very much interested in writing some extensions to your bare bones xmppd server, once I get a grasp of how it is layed out, and how best to hack in feature stubs. I hope my "complaints" dont discourage you! Keep up the work, the jabber community needs more dedicated coders like you. 

> > >
> > > Probably you are using xmppd.py with old xmpppy library. Try using
> > > version, included in xmppd.tar.gz package.
> >
> > Actually, I'm making the assumption that cvs mainline is :basically:
> > functional code.
> My main CVS repository resides on my hard disk because of too slow channel to 
> SF from my home (actually a very busy 9600bps link). So SF's CVS check ins 
> are rare now and xmppd.py and xmpppy reposytoryes are out-of-sync sometimes.
> The nxvoc feature was added to xmpppy code just before xmppd-0.1 release and 
> then I've considered it harmful and removed it.
>
So this means your dev code is on your local machine (jeez, make backups!)and at stable points you commit up to the SF cvs server?

I'll grab a tarball for now and play with it. A CHANGES or NOTES file might be of some help, if you can note which features you add as you go, and checkout cvs to make tarballs. 


Thanks!
-=C=- 

Re: [Xmpppy-devel] what is "stanza"

[Alexey N. <sn...@pe...>]

=F7 =D3=CF=CF=C2=DD=C5=CE=C9=C9 =CF=D4 =F3=D2=C5=C4=C1 29 =F3=C5=CE=D4=D1=
=C2=D2=D8 2004 08:44 oboe =CE=C1=D0=C9=D3=C1=CC(a):
> > > > confusing code.
> I still stand by my statement (:
> Since you write no documentation, can you at least add a couple simple
> comments as you go? I'd like to help, but your code is not the :most: self
> explanitory. Python is not my first language.
I have nothing to complain. The xmppd.py project targets for several goals =
and=20
"well-documented" is among them. I'll try to start acheving it.

> > The stanza is first-level node in xml stream with name one of
> > 'message','iq' or 'presence'.
> > In this example stanza can come in as Node class instance or already
> > serialised and of <type string>. Hence the check for the python class
> > type.
> >
> > > > This is the error running xmppd.py
> > > >
> > > >   File "./xmppd.py", line 96, in send
> > > >     self._owner.enqueue(self,stanza)
> > > >   File "./xmppd.py", line 216, in enqueue
> > > >     elif type(stanza)<>type(''): stanza =3D
> > > > stanza.__str__(nsvoc=3Dsession.Stream.nsvoc).encode('utf-8') TypeEr=
ror:
> > > > __str__() got an unexpected keyword argument 'nsvoc'
> >
> > Probably you are using xmppd.py with old xmpppy library. Try using
> > version, included in xmppd.tar.gz package.
>
> Actually, I'm making the assumption that cvs mainline is :basically:
> functional code.
My main CVS repository resides on my hard disk because of too slow channel =
to=20
SF from my home (actually a very busy 9600bps link). So SF's CVS check ins=
=20
are rare now and xmppd.py and xmpppy reposytoryes are out-of-sync sometimes.
The nxvoc feature was added to xmpppy code just before xmppd-0.1 release an=
d=20
then I've considered it harmful and removed it.

> I've also had to comment out the psyco calls, considering=20
> I am not on an x86 platform.
Probably I should write some code to detect host platform.

=2D-=20
Respectfully
Alexey Nezhdanov

Re: [Xmpppy-devel] what is "stanza"

[oboe <ob...@en...>]

> > > confusing code.
I still stand by my statement (:
Since you write no documentation, can you at least add a couple simple comments as you go? I'd like to help, but your code is not the :most: self explanitory.
Python is not my first language.
 
> The stanza is first-level node in xml stream with name one of 'message','iq' 
> or 'presence'.
> In this example stanza can come in as Node class instance or already 
> serialised and of <type string>. Hence the check for the python class type.
> > >
> > > This is the error running xmppd.py
> > >
> > >   File "./xmppd.py", line 96, in send
> > >     self._owner.enqueue(self,stanza)
> > >   File "./xmppd.py", line 216, in enqueue
> > >     elif type(stanza)<>type(''): stanza =
> > > stanza.__str__(nsvoc=session.Stream.nsvoc).encode('utf-8') TypeError:
> > > __str__() got an unexpected keyword argument 'nsvoc'
> Probably you are using xmppd.py with old xmpppy library. Try using version, 
> included in xmppd.tar.gz package.
Actually, I'm making the assumption that cvs mainline is :basically: functional code. I've also had to comment out the psyco calls, considering I am not on an x86 platform.

> 
> -- 
> Respectfully
> Alexey Nezhdanov


cheers!
-=C=-
> 

Re: [Xmpppy-devel] what is "stanza"

[Alexey N. <sn...@pe...>]

=F7 =D3=CF=CF=C2=DD=C5=CE=C9=C9 =CF=D4 29 =F3=C5=CE=D4=D1=C2=D2=D8 2004 07:=
45 Peter Saint-Andre =CE=C1=D0=C9=D3=C1=CC(a):
> On Tue, Sep 28, 2004 at 05:06:19PM -0700, oboe wrote:
> > I see many references to an object named 'stanza'
> >
> > Where is this from? What library?
> >
> > in xmmpd.py:
> >
> >         if feature not in self.features: self.features.append(feature) =
 =20
> >     elif type(stanza)<>type(''): stanza =3D
> > stanza.__str__(nsvoc=3Dsession.Stream.nsvoc).encode('utf-8')
> >
> > This appears to make up for parts of stanza not being defined, this is
> > confusing code.
The stanza is first-level node in xml stream with name one of 'message','iq=
'=20
or 'presence'.
In this example stanza can come in as Node class instance or already=20
serialised and of <type string>. Hence the check for the python class type.
> >
> > This is the error running xmppd.py
> >
> >   File "./xmppd.py", line 96, in send
> >     self._owner.enqueue(self,stanza)
> >   File "./xmppd.py", line 216, in enqueue
> >     elif type(stanza)<>type(''): stanza =3D
> > stanza.__str__(nsvoc=3Dsession.Stream.nsvoc).encode('utf-8') TypeError:
> > __str__() got an unexpected keyword argument 'nsvoc'
Probably you are using xmppd.py with old xmpppy library. Try using version,=
=20
included in xmppd.tar.gz package.

=2D-=20
Respectfully
Alexey Nezhdanov

Re: [Xmpppy-devel] what is "stanza"

[Peter Saint-A. <st...@ja...>]

A stanza is defined in the XMPP-Core spec. Basically it is oe of these:

<message/>
<presence/>
<iq/>

Qualified by "jabber:client" or "jabber:server".

/psa

On Tue, Sep 28, 2004 at 05:06:19PM -0700, oboe wrote:
> I see many references to an object named 'stanza'
> 
> Where is this from? What library?
> 
> in xmmpd.py:
>        
>         if feature not in self.features: self.features.append(feature)        elif type(stanza)<>type(''): stanza = stanza.__str__(nsvoc=session.Stream.nsvoc).encode('utf-8')
> 
> This appears to make up for parts of stanza not being defined, this is confusing code.
> 
> This is the error running xmppd.py
> 
>   File "./xmppd.py", line 96, in send
>     self._owner.enqueue(self,stanza)
>   File "./xmppd.py", line 216, in enqueue
>     elif type(stanza)<>type(''): stanza = stanza.__str__(nsvoc=session.Stream.nsvoc).encode('utf-8')
> TypeError: __str__() got an unexpected keyword argument 'nsvoc'
> 
> 
> help?
> 
> -=C=-
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Xmpppy-devel mailing list
> Xmp...@li...
> https://lists.sourceforge.net/lists/listinfo/xmpppy-devel
> 

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php