{5} Assigned, Active Tickets by Owner (Full Description) (101 matches)

Merge web2-access forward, rename to have this ticket in the name.

(04:29:05) exarkun: Tv: Hello
(04:29:17) exarkun: Tv: What are you thoughts regarding /branches/tv/web2-access?
(10:29:06) Tv: exarkun: i think nobody ever reviewed web2-access
(10:29:28) Tv: exarkun: i still think it's a nice feature
(10:48:39) exarkun: Tv: The implementation seems contrary to the typical manner of authentication and authorization in Twisted.
(11:30:25) Tv: exarkun: feel free to comment further on *how* you would like it to look
(11:47:10) exarkun: Tv: cred wooo
(11:47:47) Tv: exarkun: yes, well, see how well the original web cred integration worked
(11:48:01) exarkun: Tv: fucking _fabulously_ what are you talking about?
(11:48:23) Tv: exarkun: about the fact that most people can't use it
(11:48:31) _keturn: are you talking about some ticket I should be paying attention to?
(11:48:32) exarkun: Tv: everyone can and must use it
(11:48:50) exarkun: _keturn: we're not even talking about a ticket. :)
(11:48:52) Tv: exarkun: nice disconnection, let me know when you want to come back to reality ;)
(11:48:58) radix: Tv: Why can't they use it?
(11:49:11) Tv: besides, cred does mostly user auth
(11:49:18) Tv: there's plenty of other ACL stuff
(11:49:24) Tv: on the phone
(11:49:36) exarkun: Tv: don't forget that "auth" is short for two things :)
(11:49:38) radix: Yes, ACL is out of the scope of cred. That is authorization.
(11:49:44) exarkun: Tv: an ACL is just one kind of authorization.
(11:49:50) Tv: radix: web2-access is meant to be ACL
(11:49:50) exarkun: radix: and cred does authorization
(11:49:54) exarkun: in addition to access to control
(11:49:57) exarkun: erasdlkj
(11:49:57) radix: well, ok
(11:50:00) exarkun: in addition to authentication
(11:50:03) radix: it gives you the first step to authorization :)
(11:50:16) exarkun: ACLs can be implemented with an avatar that has ACL logic in it
(11:51:06) radix: Tv: anyway, you didn't explain why people can't use cred
(11:51:18) radix: Tv: I will patiently await the end of your phone call.
(13:14:14) Tv: exarkun: so
(13:14:33) Tv: exarkun: one of the things i like about web2-access is that you can plug in ACL enforcers at any point in the resource tree
(13:15:20) Tv: exarkun: what i tend to do is have a full self-contained "app" that i just plug in to the resource tree, and the app takes care of its own ACL enforcement
(13:15:43) Tv: exarkun: and if you want global sysadmin-configured ACL enforcing, you can just use the same mechanism at the top level
(13:17:11) foom: OMG this is another conversation I've had like 50000 times, isn't it?
(13:17:15) foom: I think it's even on a ticket now
(13:17:56) Tv: probably yes
(13:18:58) foom: http://twistedmatrix.com/trac/ticket/2042
(13:23:21) Tv: most of that ticket seems to be mostly concerned about authenticating users
(13:23:39) Tv: and authorizing based on username
(13:23:46) Tv: web2-access also does source-IP etc
(13:30:27) Tv: the biggest connection between the web2-access branch and #2042, that i can see, is that web2-access would read that mythical userid string
(13:30:31) Tv: and allow comparing it
(13:30:45) Tv: but that's just one of the tests in web2-access
(13:31:45) foom: well, the whole philosophical argument you were starting to espouse is exact same thing, I think, as was being argued there.
(13:32:09) Tv: is anyone actually saying t
(13:32:11) Tv: err
(13:32:32) Tv: okay
(13:32:33) Tv: honestly
(13:32:46) Tv: as far as i care, glyph is an abstraction astronaut
(13:33:32) foom: btw, how does your thing compare with dav-acl-1608-4
(13:33:32) Tv: what i really want is a simple way to have a subtree of objects where one lower level subtree is only accessible to localhost
(13:36:11) foom: Tv: From the face of it, they're both doing quite similar things
(13:36:19) Tv: foom: perhaps
(13:36:30) Tv: i'm trying to figure out what's non-dav in 1608
(13:39:31) Tv: well on the simplest level, #1608 gives you nothing unless you drink DAV koolaid
(13:39:42) foom: only because it was implemented only for DAV resources
(13:39:56) foom: (I think)
(13:39:59) Tv: trying to find the generic bits from inside of it
(13:40:18) foom: dreid could probably do a better job of helping
(13:41:01) Tv: +        return davxml.ACL(*[
(13:41:01) Tv: +            davxml.ACE(
(13:41:01) Tv: +                davxml.Grant(davxml.Privilege(privilege)),
(13:41:01) Tv: +                davxml.Principal(davxml.All())
(13:41:01) Tv: +            )
(13:41:01) Tv: +            for privilege in privileges
(13:41:01) Tv: +        ])
(13:41:34) dreid: nothing is non-dav in 1608
(13:41:45) dreid: it is an implementation of the WebDAV ACL protocol.
(13:41:54) dreid: It is more or less entirely dav specific.
(13:42:03) Tv: yeah, that's what it seemed like
(13:42:13) Tv: web2-access is more like
(13:42:14) Tv:     # /friends subtree is shown to these hosts
(13:42:14) Tv:     And( Segments('friends'),
(13:42:14) Tv:          Or( Network('10.0.1.0/255.255.255.0'),
(13:42:14) Tv:              Network('10.0.2.0/255.255.255.0'),
(13:42:14) Tv:              ),
(13:42:14) Tv:          ),
(13:42:24) Tv: talking about url segments, ip addresses, etc
(13:42:29) dreid: And figuring it out how to make it not dav specific is not my idea of a good time.
(13:42:30) exarkun: Tv: you can put multiple resource guards into a single url hierarchy
(13:42:40) dreid: also that thing exarkun said.
(13:42:41) foom: dreid: oh okay, I thought it had some stuff that might be more generic
(13:42:48) dreid: foom: generic is hard.
(13:42:49) Tv: exarkun: i want one login only, though
(13:42:50) exarkun: dreid: any progress being made on moving that branch somewhere?
(13:42:57) foom: exarkun: moving?
(13:42:59) exarkun: Tv: and that works too
(13:43:04) foom: exarkun: you mean merging?
(13:43:13) Tv: exarkun: good
(13:43:15) exarkun: causing any changes in it at all :)
(13:43:17) radix: foom: *that* question was asked a long time ago
(13:43:25) dreid: exarkun: No, we'll figure it out after the auth stuff settles down and we ship leopard.
(13:43:26) Tv: exarkun: now, do you think i should use guard for IP-based limits?
(13:43:36) exarkun: Tv: yes
(13:43:57) Tv: exarkun: maybe web2 has something called "guard" that is very different from nevow's guard..
(13:44:09) dreid: Tv: I've avoided calling it guard.
(13:44:35) Tv: exarkun: but web2-access's AccessControl tries to be such a thing you can put at any place in the tree
(13:44:35) exarkun: Tv: the shortcoming of nevow's guard is that it doesn't make credential type easily configurable
(13:44:46) exarkun: Tv: it has a hardcoded list of about three things it supports
(13:44:57) foom: web2-access's AccessControl is basically a guard, isn't it?
(13:45:12) Tv: foom: depending on what you mean by "guard", but I guess yes
(13:45:28) Tv: foom: it guards the resources underneath it in the tree
(13:45:43) exarkun: foom: the biggest difference, I think, is that with AccessControl you call a function and it returns a deferred which tells you if access is allowed or not
(13:45:44) Tv: according to a pluggable set of rules
(13:45:49) exarkun: foom: and then you do something based on that result
(13:46:02) foom: exarkun: so it's half of guard.
(13:46:14) exarkun: I suppose
(13:46:19) Tv: yeah, that's the IRule bit
(13:46:29) Tv: and AccessControl lets you combine those with And, Or, Not etc
(13:46:32) idnar: can I change the usage output from t.p.u.O to show the names of "positional" args?
(13:46:39) dreid: the stuff in #1608 works similarly, and there has been quite a bit of discussion about wether or not that is completely wrong.
(13:46:49) dreid: and by discussion I mean exarkun and glyph yelling at me. :)
(13:47:01) foom: glyph and exarkun like to yell at people about guard stuff
(13:47:35) exarkun: I don't like yelling at people at all
(13:47:48) itamar: I would argue that IP-based access control is orthogonal
(13:47:49) exarkun: I would like it if all of you jerks would stop making me do it
(13:47:50) exarkun: ;)
(13:47:50) Tv: exarkun: yes your style is more *passive* aggressive
itamar itamarst
(13:47:58) exarkun: itamarst: SHUT UP YOU DON'T KNOW ANYTHING YOU ASS GO AWAY
(13:48:04) itamar: for a *specific* resource
itamar itamarst
(13:48:09) itamar: not with a subtree language
(13:48:18) exarkun: itamarst: RAAAAAAAAAAAAAAAAAAAAAAAGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
(13:48:31) itamar: because otherwise how would you hook it up to cred!@
itamar itamarst
(13:48:34) ***idnar gets popcorn
(13:48:49) Tv: itamar: the point of web2-access is that you can say things like "https OR localhost"
(13:49:14) itamar: that's probably something you want per-avatar
(13:49:14) itamar: but
(13:49:27) itamar: the basic implementation would have to be for resources
(13:49:32) itamar: since avatars are resources in web
(13:49:58) foom: don't start with that one again. :P
(13:50:10) itamar: ok whatver
(13:50:20) itamar: I'll go back to reading
(13:50:22) foom: there has to be a lower level function which does the access control decision. web2-access might be a good implemtation of that, and should be reviewed on that basis, at least.
(13:50:48) foom: how that is hooked up to other stuff is a point of argument, but however that happens, the lower level function is the same
(13:51:44) foom: That's how I'd like to see this branch move forward.
(13:52:11) exarkun: Okay!
(13:52:21) exarkun: It sounds like we aren't just going to delete it right now, then.
(13:52:31) Tv: foom: yay!
(13:52:34) exarkun: So how about someone files a ticket saying the thing foom just said
(13:52:42) Tv: foom: that works for me 100%
(13:52:48) exarkun: And then does the appropriate svn dance to make the branch line up with it
(13:53:22) exarkun: Anyone want to volunteer to do that?
(13:53:35) Tv: i still claim lack of understanding of goal
(13:53:43) foom: Tv: merge branch forward with a ticket number in it
(13:53:50) exarkun: The goal is to get rid of the "/branches/tv" directory in svn. ;)
(13:54:04) foom: Tv: then put it up for review and see if we can get it merged.
(13:54:20) Tv: ok
(13:54:39) foom: assuming it's ready for review, I don't know if you had it at that point or not?
(13:54:48) exarkun: And once all of the user branches directories are gone, I think we might generalize that goal a little bit to resolving tickets with existing branches associated with them.
(13:55:07) exarkun: And once we make some progress on that, we might try to tackle the repo reorg
(13:55:46) dreid: omg
(13:55:54) exarkun: Tv: So you will make the ticket and merge the branch forward?
(13:56:14) Tv: yeah

The reactor was unclean on a couple of tests after calling signalProcess("KILL")

adding a call to stopPolling() cleaned up the polling files. when a process is killed

self._stopPolling()

We have to use the hashlib module available since python 2.5.

Note that I saw this because stdio tests are failing on python trunk. I'm not sure it should be sensitive to warnings emitted...

It also doesn't have a test-case-name or a copyright notice.

• It should have unittests written,
• it's code brought in line with the coding standard,
• it's longdesc pointing to the HTML documentation for the twistd tap plugin,

In twisted.protocols.loopback:

_loopbackAsyncBody is used as the callback for deferreds called when _LoopbackQueue objects are updated. This callback returns a deferred. As a result, the calling deferred's _continue method is added to the returned deferred's callbacks. This creates a chain that increases by a link every time that _loopbackAsyncBody is called. If a test does lots of I/O, this chain will get quite large.

If the test causes loseConnection on a _LoopbackTransport, _LoopbackTransport will be called and will return the result of calling twisted.internet.deferred.suceed, which is an already-called deferred. When the calling deferred adds it's _continue method to the alead-called deferred's callbacks, it will try to call all of the chained callbacks. This results in a 'maximum recursion depth exceeded' exception.

I'm not sure why this callback returns a deferred. I guess it has something to do with "@return: A L{Deferred} which fires when the connection has been closed and both sides have received notification of this." from loopbackAsync's docstring. The implementation takes a wildly round-about and inefficient approach to implementing this. It seems as though there should be a much simpler and more direct way to achieve this.

The AMP protocol needs protocol-level documentation in the style of doc/core/specifciations/banana.xhtml.

An object may implement more than one interface, and there's no use-case that I'm aware of to restrict this API to proxying for only one interface at a time.

The prototypical use-case that I do know of, xmantissa.sharing, which implements a similar proxy class, requires the ability to share (or not) multiple interfaces. It does this to limit access; for example, a user who can retrieve an IRead proxy for object X might not be able to retrieve the IWrite proxy.

This is high priority because I'd prefer to avoid a deprecation, since this API is still unreleased.

Currently, twisted (process.py) does one waitpid for every process that it has spawned. If Twisted has a few thousand plus child processes alive still this can cause a huge slowdown (after a few hours twisted was spending 90% of its time doing waitpid). Alternatively, twisted could call waitpid(-1) just once to check if there are any processes that can be reaped. According to 'man waitpid', this should be called in a loop until there are no more child processes to be reaped. We're currently using a similar modification on our servers, and twisted rarely consumes more than 2% of the CPU now (previously was upwards of 20% .... would require restarts every 7-8 hours).

Twisted currently needs to install a SIGCHLD handler for reactor.spawnProcess to work reliably. This is problematic when Twisted is used with other libraries that depend on SIGCHLD (e.g. the standard library's subprocess module depends on SIGCHLD being left as SIG_DFL, otherwise it can get EINTR at unexpected times). Hence the reactor can be run with the installSignalHandlers=False flag, but then reactor.spawnProcess isn't reliable.

However, when run with installSignalHandlers=False Twisted could use a different strategy for notifications of subprocess termination. spawnProcess could first fork a process that keeps a single file descriptor back to the parent open, and then forks the child that the caller of spawnProcess requested. Then first subprocess could simply do:

    pid = os.fork()
    if pid:
       returnVal = wait(pid)
       os.write(fd, str(returnVal))
       os.close(fd)
       os._exit()

i.e. wait for the child process to finish, and then let the original process know the return value and exit. The original process would know that the subprocess was done when it saw the fd get closed, and would know what the return value was.

It's ugly, but it might be better than nothing.

ready for discussion :-)

E.g. bzrlib.tests.TestCase? is not documented, and it's defined in bzrlib/tests/init.py.

It's good that we still have these pages so that links don't randomly break, but we need to direct people who arrive at these pages to the real pages.

For example, the project pages at tm.com/projects should redirect to tm.com/trac/wiki/TwistedProjects. If the old pages are no longer maintained we don't want people reading them based on old links.

The side bar on the wiki front page needs some CSS TLC. There should probably be a general "sidebar" CSS class, and then div ids such as "download" and "donate" can inherit from that.

The "sidebar" CSS class needs to elimiate the excessive white space that is currently visible between the donation link and the Twisted book.

I would like to be able to parse NetFlow data from routers (or software probes such as softflowd), thus providing the ability to create Twisted-based NetFlow collectors. The first step in the support of NetFlow is creating a Twisted protocol.

Below are some notes on the NetFlow header and record formats.

NetFlow v5 Header

NetFlow v5 Record Format

As I gather information relavant to maintaining the Twisted Web Presence, I will update this ticket. Hopefully this will not only be of use to me, but to those who come afterwards as well.

try:
    1/0
except:
    log.err(None, "foo")

or log.err(_why="foo")

trying to pass why= directly causes the following error:

    msg(failure=_stuff, why=_why, isError=1, **kw)
TypeError: msg() got multiple values for keyword argument 'why'

Which is dumb. Either _why= should be renamed to why= or the special passing of why=_why should only happen if _why is not None.

Fixing this ticket should also entail fixing #2567

This also involves unix commands. (Jp: "Not that hard")

Having a stream (the thing from web2) for an FTP client would be handy.

Conversation from IRC:

htj spiv: /begin shameless plug: If you could add the possiblity of getting a stream (web2) for retrieving a file, you could make me quite happy.
spiv htj: I think you might be able to do that with an adapter, not sure if it's already written.
spiv htj: But I like that idea, please file a bug :)
spiv Or a "ticket", as this new-fangled thing calls them ;)
htj spiv: talked with exarkun and dreid about it yesterday, and I don't think it is. I'l file a ticket.

1. go to http://twistedmatrix.com/trac/newticket

2. In the field at the top of that form labeled "Your email or username:", enter your email.

3. Submit the ticket

4. get something like this:

Traceback (most recent call last):
  File "/home/trac/Projects/trac/trunk/trac/web/main.py", line 283, in dispatch_request
    dispatcher.dispatch(req)
  File "/home/trac/Projects/trac/trunk/trac/web/main.py", line 170, in dispatch
    resp = chosen_handler.process_request(req)
  File "/home/trac/Projects/trac/trunk/trac/ticket/web_ui.py", line 83, in process_request
    self._do_create(req, db)
  File "/home/trac/Projects/trac/trunk/trac/ticket/web_ui.py", line 138, in _do_create
    ticket.insert(db=db)
  File "/home/trac/Projects/trac/trunk/trac/ticket/model.py", line 196, in insert
    tktObs.ticket_added(self)
  File "/home/trac/projects/trac/plugins/TICKET_EMAILER_MAN-ONE-py2.4.egg/ticket_emailer/ticket_emailer.py", line 128, in ticket_added
  File "/home/trac/projects/trac/plugins/TICKET_EMAILER_MAN-ONE-py2.4.egg/ticket_emailer/ticket_emailer.py", line 95, in ticketAddedMessage
  File "/home/trac/projects/trac/plugins/TICKET_EMAILER_MAN-ONE-py2.4.egg/ticket_emailer/ticket_emailer.py", line 86, in baseMessage
  File "/home/trac/projects/trac/plugins/TICKET_EMAILER_MAN-ONE-py2.4.egg/ticket_emailer/ticket_emailer.py", line 53, in ticketVars
RuntimeError: Visit the 'User Configuration' page and enter an email address before you create a ticket.

The trac search doesn't cover these pages.

these objects' docstrings are not proper epytext:

twisted.python.modules twisted.python.modules._ModuleIteratorHelper.getitem twisted.python.modules._ModuleIteratorHelper.getitem twisted.python.zshcomp twisted.vfs.backends.adhoc.AdhocDirectory?.child twisted.vfs.backends.adhoc.AdhocDirectory?.child twisted.vfs.backends.inmem.FakeDirectory?.child twisted.vfs.backends.inmem.FakeDirectory?.child twisted.vfs.ivfs.IFileSystemContainer.child twisted.vfs.ivfs.IFileSystemContainer.child twisted.words.protocols.jabber.client.XMPPClientFactory twisted.words.protocols.jabber.client.XMPPClientFactory twisted.words.xish.domish.Element twisted.web2.dav.xattrprops.xattrPropertyStore twisted.web2.dav.resource.DAVPropertyMixIn twisted.web2.client.http.EmptyHTTPClientManager.clientPipelining twisted.web2.client.http.EmptyHTTPClientManager.clientPipelining twisted.web2.client.http.EmptyHTTPClientManager.clientPipelining twisted.web2.client.interfaces.IHTTPClientManager.clientPipelining twisted.web2.client.interfaces.IHTTPClientManager.clientPipelining twisted.web2.client.interfaces.IHTTPClientManager.clientPipelining twisted.mail.maildir.StringListMailbox?.listMessages twisted.mail.maildir.StringListMailbox?.getMessage twisted.mail.maildir.StringListMailbox?.listMessages twisted.mail.maildir.StringListMailbox?.getMessage twisted.mail.pop3.IMailbox.listMessages twisted.mail.pop3.IMailbox.getMessage twisted.mail.pop3.IMailbox.listMessages twisted.mail.pop3.IMailbox.getMessage twisted.mail.pop3.Mailbox.listMessages twisted.mail.pop3.Mailbox.getMessage twisted.mail.pop3.Mailbox.listMessages twisted.mail.pop3.Mailbox.getMessage twisted.internet.defer.inlineCallbacks twisted.internet.defer.inlineCallbacks twisted.internet._dumbwin32proc._findShebang twisted.internet._dumbwin32proc._findShebang twisted.spread.jelly.Jellyable.jellyFor twisted.spread.flavors.RemoteCopy?.unjellyFor twisted.spread.flavors.RemoteCopy?.unjellyFor twisted.spread.flavors.RemoteCache?.unjellyFor twisted.spread.flavors.RemoteCache?.unjellyFor twisted.spread.jelly.Jellyable.jellyFor twisted.spread.jelly.Jellyable.jellyFor twisted.spread.jelly.Jellyable.jellyFor twisted.spread.jelly.Unjellyable.unjellyFor twisted.spread.jelly.Unjellyable.unjellyFor twisted.spread.banana.Banana.setPrefixLimit twisted.spread.banana.Banana.setPrefixLimit

The API documentation should be marked up with version information. Using an epytext field for this probably makes the most sense, but I don't really care so much about the actual mechanism, as long as the information is present.

One annoying factor is that we don't always know the next version number for the full development time leading up to it. It might be nice to be able to drop a marker value in and have part of the release process replace it with a real value.

There should be a similar standard for deprecations.

It would be nice to point people from the API docs for a module to the howto describing its usage. One reason is that sometimes a Google search will turn up the former and not the latter. Another is that because of ticket #38, sometimes fundamental parts of a module are not described in the API docs (e.g. twisted.python.log.msg) but do appear in the howto. Finally, in some cases the howto documents behavior that is not described in the API docs.

Discussed on IRC with <jml>:

The core documentation at http://twistedmatrix.com/projects/core/documentation/howto/index.html discusses reactor.callLater in the scope of scheduling of events, but neglects to mention reactor.callWhenRunning, which should be emphasized as a clear(er) way to queue an action to run "immediately." We believe this documentation should be updated to include a discussion of this method.

Usage of this has been discourage for some time however it should probably be listed in the coding standard.

As exarkun points out it's also OK for the right side of the % operator to be a dict.

In particular, twisted/names/dns.py IRecord. Others if they exist.

This would catch things like #1801.

Currently IRequest contains several attributes which are used to access the requeste