On May 2, 2014, at 5:45 PM, David Stainton wrote:
> I'm starting to think about the deployment issues... Perhaps someone
> on the list knows of the "correct" setup.py (distutils/setuputils?)
> procedure to deploy twisted plugins? I shall have to research this
> soon. For now my hacky development/
Thanks. Sure thing. Yes I have every intention of contributing
endpoint parsers to txtorcon and txsocksx for use with tor.
Both of these could make it much easier for developers to make their
applications tor friendly.
The endpoints/endpoint parsers api is brilliant! When the tor
client/server end
Ah yeah... twisted endpoints that support udp...
Perhaps when Yawning Angel finishes Lightweight Obfuscated Datagram
Protocol (LODP) there will be interesting things we can do with
this... and a more immediate perceived need for twisted datagram
endpoint interfaces.
On Fri, May 2, 2014 at 9:16 PM
>> Ah ha! Of course it is so obvious now that you point it out to me.
>> The onion endpoint parser can do this setup work in it's `listen`
>> method which returns a `Deferred`.
>> Thanks for your observation/advice!
>
> Cool! Thanks for doing this. Can I pull it into txtorcon when it's
> finished?
On May 2, 2014, at 6:59 AM, David Stainton wrote:
> Today I wrote an endpoint parser for Meejah's txtorcon Tor Hidden
> Service endpoint.
This is fantastic. Basically this is _exactly_ the use-case that we had in
mind when designing the endpoint parser plugin APIs.
Thanks so much for doing i
On May 2, 2014, at 1:02 PM, meejah wrote:
> Another point for this is that "someday" tor will have UDP support...
There's a reason that the existing interfaces all have "stream" in their names
:-).
The main reason we didn't do "datagram" at the same time is that there's a
pretty clear client/
David Stainton writes:
> Ah ha! Of course it is so obvious now that you point it out to me.
> The onion endpoint parser can do this setup work in it's `listen`
> method which returns a `Deferred`.
> Thanks for your observation/advice!
Cool! Thanks for doing this. Can I pull it into txtorcon whe
Ah ha! Of course it is so obvious now that you point it out to me.
The onion endpoint parser can do this setup work in it's `listen`
method which returns a `Deferred`.
Thanks for your observation/advice!
Cheers!
David
On Fri, May 2, 2014 at 3:01 PM, wrote:
> On 02:53 pm, dstainton...@gmail.co
On 02:53 pm, dstainton...@gmail.com wrote:
I get what you are saying... but let's back up a second;
foolscap (in my branch
https://github.com/david415/foolscap/tree/endpoint_descriptors_server2)
uses clientFromString and serverFromString to translate twisted
endpoint descriptors into endpoint obj
I get what you are saying... but let's back up a second;
foolscap (in my branch
https://github.com/david415/foolscap/tree/endpoint_descriptors_server2)
uses clientFromString and serverFromString to translate twisted
endpoint descriptors into endpoint objects... AND foolscap
doesn't know any details
Sounds like a good idea, I'll make a note to do it and write it in the release
process once I've done it.
- HawkOwl
> On 2 May 2014, at 3:33, Glyph Lefkowitz wrote:
>
>
>> On Apr 30, 2014, at 12:09 PM, Donald Stufft wrote:
>>
>> There is a drop down for default release in the RTD admin pan
On 2 May 2014 15:59, David Stainton wrote:
> This will work fine for the txsocksx tor client endpoint parser I
> wrote... However the txtorcon Tor Hidden Service endpoint setup
> requires a deferred to fire once the tor process is started... This
> means that the endpoint parser needs to return a
Greetings,
Today I wrote an endpoint parser for Meejah's txtorcon Tor Hidden
Service endpoint.
Now that we have foolscap ported to twisted endpoints (branch needs
review but I should probably rebase first) we'd like to be able to
simply specify an "onion" endpoint descriptor in Tahoe-LAFS
configu
13 matches
Mail list logo
