up for adoption: supporting y and z-modem batch file transfers

[jquast]

Let us complete @tehmaze vision of the python 'modem' module, https://pypi.python.org/pypi/modem/1.0 and https://github.com/tehmaze-labs/modem

• design: how should an API for batch file send/recv appear? Agree on a new send/recv pattern.
• research: is z-modem still a lot of work to implement?
• laborers: we're all too busy, any volunteers?

Another API, https://pypi.python.org/pypi/serialXfer is released, based on this one, with only YMODEM support, though documented as ZMODEM as TODO. Can we collaborate with this Jason Morgan?

We also have partial y-modem send() contributed as PR #24.

Incidentally, I also own the modem.xyz domain for documentation.

[tesch1]

To start the discussion:

I'd say separate the YMODEM from ZMODEM goals. YMODEM is much simpler and can be build on top of XMODEM. ZMODEM has different packet structure / stream coding and will need lots of new code.

A batch send needs to have a list of files to be sent. YMODEM has a few optional fields (length, modification date, mode, serial number, other) in the file information packet, could also add args to en/dis able those. What else?

A batch receive needs a directory to put the files in. Default cwd, could pass in something else. Maybe flags to (dis)allow directory traversal and filename cleanup. What else?

ZMODEM has a receive initiate mode, where it can initiate receives of specific or globbed filenames. This should probably have its own interface separate from send/recv.

ps. nugget of joy from zmodem docs:
"We were also keen to the pain and $uffering of legions of
telecommunicators whose file transfers have been ruined by communications
and timesharing faults. ZMODEM's file transfer recovery and advanced file
management are dedicated to these kindred comrades."

[yupeng-zglue]

Thanks for the work put into creating this library.

I would like to ask if there has been any progress with supporting zmodem.

[jquast]

I don’t have any time in the coming year.. I sense the same is for our co-maintainers.

I usually contribute to FOSS projects during periods of unemployment, which cannot be predicted.

Zmodem would be a fun problem to do, near the top of my list, but I’ll probably never get to it.

[tesch1]

There are open questions in this thread and in #24 waiting for feedback. I suspect anyone stopping by who sees the state of ymodem (undefined interface, no progress in definition) is likely to be discouraged from committing any time to it. Just sayin :o)

[jquast]

I can't attend to it, but you are more than welcome to ask for commit access from @tehmaze like I did and manage the next pypi release and go ahead with whatever design you feel like doing, from my perspective, it's not even my project, its just something i have commit access to an was once excited about. you're welcome to take the next turn. I hope you too are also too busy to attend to the next PR :)

[tesch1]

hey, @tehmaze, what do you say?

let's finish this thing. or at least define what the interface should be, so that passers-by can finish it, and PRs are easy-to-evaluate. the state of {xyz}-modem in python makes me weepy ;o) there are a bunch of half-finished projects trying to implement {xyz}-modem, and none of them are definitive. this one seems to be the best place to start.

[marksteward]

https://github.com/tehmaze-labs/modem/blob/multi-protocol/modem/protocol/zmodem.py also looks like a possible place to start

[ApiumJacob]

@marksteward I think I've fallen into a trap... I've forked the tehmaze-labs modem project and fixed some issues on the multi-protocol branch to get y-modem working in Py2.7. It looks like the same work keeps getting done over and over by others that have fallen into this honey pot. I have a little bit of time that I can help with this project but it looks like pull request are being ignored tehmaze and tehmaze-labs.

https://github.com/ApiumJacob/modem/tree/ymodem-fixes