Hi!
Enus Linden wrote:
Locklainn wrote:
Here are some things I think we should start to answer:
1. What are the protocols we want to implement? The wiki page for the
Protocols has an (incomplete and not very defined) listing of some of
the protocols, but which of those do we want to implement?
(wiki.secondlife.com/wiki/Protocol) aka, what are some of the things
we want to be able to do with the Client Library?
anything and everything, though, I do believe that we should prioritize.
Locklainn, might you be able to come up with a list of what you see out
there, and we can start from there? a rough sketch in my mind looks
something like:
1. login and establish/maintain presence
2. parse the data sent via the communication channels (event queue/UDP)
3. start building out functionality in the client
I would like to soon have something which actually is usable from a
command line at least, like IM, checking friends online etc.
2. Framework - it seems we have set out to design a framework for
testing. Are we writing a framework (like unit testing) or are we just
writing test suites that use the client library?
framework all the way. I'll help sketch that out once I get back in on
Monday.
I don't really get the difference as the unit test framework is indeed a
framework ;-)
Rough ideas here:
We need some way of configuring tests so that you can give
usernames/passwords, URLs etc. to the test so that they know what to
test. This can be maybe passed by via some .ini or XML-file.
We might want to have separate test suites for separate parts like agent
domain/region domain and also smaller modules (if some component is
known to not yet implement e.g. inventory then there is no need to test it).
We might need some way to setup certain testing scenarios. If the
inventory is empty we probably cannot retrieve something so we need to
make sure it's not empty before we test some GET (as an example).
All in all I think we can use the unit test framework and encapsulate it
in some command line tool which then can call the individual suites. A
way to pass configuration should also not be hard to be found. In Zope
we also use some feature called test layers where every layer can setup
some test environment. Some can then be bigger and more complete (but
take longer to initialize), some might be more lightweight which is
maybe enough to call lowlevel things which do not need so much setup.
Not sure we need that here though as it's probably more a networking
based test library anyway.
These are my rough thoughts on this.
-- Tao
--
Christian Scholz video blog: http://comlounge.tv
COM.lounge blog: http://mrtopf.de/blog
Luetticher Strasse 10 Skype: HerrTopf
52064 Aachen Homepage: http://comlounge.net
Tel: +49 241 400 730 0 E-Mail [EMAIL PROTECTED]
Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T
neue Show: TOPFtäglich (http://mrtopf.de/blog/category/topf-taglich/)
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
