Automatic ADTPro Server Startup

[oliverschmidt]

http://appleii.ivanx.com/prnumber6/category/a2cloud/ seems to give the impression that the ADTPro server is running after installing Raspple II. However this seems not to be true. While I can imagine that there might be reasons not to start the ADTPro server by default (maybe conflicts on serial ports?) it would be great if http://appleii.ivanx.com/prnumber6/category/a2cloud/ would reflect the actual situation, tell how to start ADTPro and provide hints on how to make it start on boot.

[knghtbrd]

ADTPro starts when the correct USB serial device appears. Do you have any connected?

[oliverschmidt]

Thanks for pointing out. Actually I'm not using serial at all. A brief background:

I'm into Ethernet / TCP/IP connectivity for A2 machines. You may know that ADTPro supports Ethernet as alternative to serial for quite some time by now. However as far as I understand the usage of ADTPro as part of A2CLOUD is focusing on the Virtual Drive feature. That feature can't be used well with Ethernet so far as the corresponding client is way to large.

However in a few days there will be a new ADTPro with an additional Virtual Drive Ethernet client for the 'Uthernet II' card. This card comes with a built-in TCP/IP stack. Making use of that allows for a much smaller footprint. In fact this Ethernet client has roughly the same size as the serial client and just like the serial client replaces the Disk II driver inside ProDOS 8.

At least from my perspective this means that the Uthernet II becomes an attractive alternative to a serial interface for the ADTPro Vrtual Drive feature. And from that point of view it becomes desirable to allow A2CLOUD to be set up with the ADTPro server using Ethernet instead of serial.

I have evaluated A2CLOUD in order to understand what needs to be changed to run ADTPro using Ethernet. I removed https://github.com/RasppleII/a2cloud/blob/master/setup/adtpro-start.txt#L11 to https://github.com/RasppleII/a2cloud/blob/master/setup/adtpro-start.txt#L22 and replaced in https://github.com/RasppleII/a2cloud/blob/master/setup/adtpro-start.txt#L26 serial with ethernet.

So far so good. But I didn't understand how ADTPro got started automatially. Therefore I opened this issue...

So at this point this issue is rather a feature request to add an Ethernet option to the A2CLOUD setup process. I'd really appreciate if you would consider this.

[knghtbrd]

Yeah, we're going to be changing how that works a fair bit. Currently we depend upon the appearance of the serial device using udev and launch ADTPro (incorrectly) when the device appears. We kill the server when it disappears. And all of this makes a lot of assumptions about your serial device configuration.

Some of that is fair and reasonable--the goal is for it to "just work" without bothering to plug in a keyboard or monitor for configuration. But you should be able to login and override that configuration for use with a sound card, a network device, or whatever you like. If you're familiar with udev and systemd, I'll prioritize some discussion about the finer points and you're welcome to jump in and begin tackling them before I get to it.

Of course all of this is of course a stopgap to the real solution Dave Schmidt hasn't actually rejected of someone taking the time to port the whole Java-based server to Python. This is not a "free" or short-term project however. I've described a process by which it and AppleCommander can be converted one class at a time to obsolescence-aware Jython 2.5, then once the whole thing has no dependency on Java, ported to CPython 2.7.2, updated to import from future that which changes, and then carried forth into modern 3.x. It's the class-by-class porting and the interim time where someone would have to have Java and Jython and all the pieces working together that's difficult. Once the porting's done, much improvement could be accomplished.

My goal with that is a Python-based ADTPro would become itself client/server based. What you'd normally start on your modern machine would be a client. It'd start up a server that listened to nothing, and you'd add an interface--network, serial, or sound card. Maybe more than one. It'd listen for ADTPro client or VSDRIVE/VEDRIVE connections on those interfaces that support it and provide some status interfaces. It could maybe give you some status about what machines are talking to it and what they're doing as well. Concurrent read access should be okay, but if something's opened as writable that'd be exclusive. It's not (yet) real network file sharing, after all. ;) When you quit out of ADTPro, you can leave the server running or not. And of course the system could start the server without the client. And the client can connect to an existing server instead of starting one.

If that sounds a bit overkill, I've already hinted at why you'd want to be able to go there eventually: Real network file sharing for the Apple // for ProDOS over serial or supported Ethernet device. AppleTalk would be faster for serial links if you've got the hardware, and at least for now it'd be compatible with more software (that might accidentally blow away VSDRIVE/VEDRIVE), but this is an incremental process here. :)

I'm kinda already thinking about the possibility of collaborating with Glenn on an Uthernet III that'd incorporate some kind of VEDRIVE-type functionality in ROM and catch the AppleTalk hooks. Now that we have ProDOS 2.4.1 with wider hardware support, there's all kinds of fun things we could come up with for that. :D

[knghtbrd]

Either way, hard to say whether it's fair to call the current serial-tied behavior a bug or an enhancement request, so I'm calling it both. And yeah we want to fix it. :)

[oliverschmidt]

But you should be able to login and override that configuration for use with a sound card, a network device, or whatever you like.

That's basically my point.

If you're familiar with udev and systemd, I'll prioritize some discussion about the finer points and you're welcome to jump in and begin tackling them before I get to it.

Rather not ;-)

My goal with that is a Python-based ADTPro would become itself client/server based. What you'd normally start on your modern machine would be a client.

Given how mobile devices supersede PCs I personally would consider a web-based approach more future-proof...

I've already hinted at why you'd want to be able to go there eventually: Real network file sharing for the Apple // for ProDOS over serial or supported Ethernet device.

Me too ;-)

AppleTalk would be faster for serial links if you've got the hardware, and at least for now it'd be compatible with more software (that might accidentally blow away VSDRIVE/VEDRIVE), but this is an incremental process here. :)

I specified a shared access between a ProDOS program using the Uthernet II and the new VEDRIVE on https://github.com/a2retrosystems/mxp/wiki/W5100-Shared-Access. Contiki follows that spec already so the Contiki web browser mounting a new disk image thru the vsd web front-end can run while the new VEDRIVE is active.

CTRL-RESET brings the Uthernet II into a defined default state and the new VEDRIVE detects that and re-initializes the Uthernet II just-in-time on next access. So it's pretty stable :-)

I'm kinda already thinking about the possibility of collaborating with Glenn on an Uthernet III that'd incorporate some kind of VEDRIVE-type functionality in ROM and catch the AppleTalk hooks. Now that we have ProDOS 2.4.1 with wider hardware support, there's all kinds of fun things we could come up with for that. :D

I suggest to follow-up on that in P2P email. My address is given on https://github.com/oliverschmidt - if you write me I'll have your address too...

[knghtbrd]

My goal with that is a Python-based ADTPro would become itself client/server based. What you'd normally start on your modern machine would be a client.

Given how mobile devices supersede PCs I personally would consider a web-based approach more future-proof...

I had the same thought, but there are two arguments against assuming the interaction will be using a web browser:

1. This is somewhat inconvenient from a shell prompt. Ideally you'd want the current GUI rendered as text-based menus in that environment. The use of a text-based browser is possible, but will increase the learning curve somewhat in ways we don't have to.
2. Python bindings for WebKit exist. With those, we can design a simple cross-platform UI that uses the latest technologies, can easily control everything, hide the "it's a web browser" ugliness, and implement things like the client-spawned server that shuts down on exit (mimicking the way ADTPro works now when not using Xvfb tricks on Debian Linux systems), handling saved authentication credentials for connection to a pre-existing or remote server, etc.

A carefully designed protocol could allow both of the above to operate if an older client connects to a newer server or vice versa. The server would provide the GUI assets or a simple menu description for the client so that as long as the handshake process works, you're good to go. As for HTML/CSS? I can write acceptable but not quite valid HTML 5 that will properly and correctly degrade to display in freakin NCSA Mosaic if I really wanted to. (I don't, but making it work in Contiki and Spectrum might be cool.)

I'm kinda already thinking about the possibility of collaborating with Glenn on an Uthernet III that'd incorporate some kind of VEDRIVE-type functionality in ROM and catch the AppleTalk hooks. Now that we have ProDOS 2.4.1 with wider hardware support, there's all kinds of fun things we could come up with for that. :D

I suggest to follow-up on that in P2P email. My address is given on https://github.com/oliverschmidt - if you write me I'll have your address too...

I'm not quite ready to do that just yet, but I think I'll open an issue against ... something ... as a wishlist item as soon as I figure out where to put it and make sure there's tags for everyone who's got interest in working on it.

If you use FaceySpace much, I've created a group there a little more friendly to end-users than GitHub issues/wikis tend to be: < https://www.facebook.com/groups/rasppleii/>

Also, it doesn't fix any of your issues with Ivan's last release, and it possibly has a few new ones, but I've dropped a beta of Raspple II for Raspbian Jessie on DropBox. It's missing a lot of polish for sure, and I need to expend some effort determining if/how upgrades are going to work from Ivan's last release. Since Ivan doesn't really use Raspbian's package facilities for anything and a lot got changed in the past year and a half, it might be a more complex transition than I'd like.

Going forward, I'll be reorganizing things into "proper" Debian ways of doing things where possible. E.g., we're writing to /srv for the sake of automating what we do, but will never delete anything from it without explicit permission which is against Debian policy but consistent with the File Hierarchy Standard that Debian adheres to. Probably contrary to both, we'll be removing recognized elements from /usr/local in favor of Debian packages that install to /usr. And while Debian has concluded it cannot distribute firmware for the popular-with-early-newworld-Mac-users Keyspan USB-serial devices at all due to that software being licensed only for distribution with a Linux distribution (and Debian non-free is declaratively not part of Debian), we'll ship it because firmware files for common USB-serial adapters declaratively ARE part of Raspple II. :) It's a transition process there as well.

The other thing is that we've lost Apple II Pi for a version or two. Pulled it due to a bug in Pi 3 UART serial and lack of a more intelligent serial configuration for the majority of folks who DON'T have Apple II Pi cards in their //e and IIgs machines, and to promote it from just an afterthought of A2CLOUD to a first class project.

Currently the best place to talk about this stuff is the Facebook group because I haven't got a scathingly brilliant alternative. Ivan ran WordPress on his site. My interest is more static site generator--as it's basically just me working on stuff for now, worrying about PHP exploits and the like is too fiddly for me. I guess there's also some UM forum space, but that's more kinda aimed at their product than mine.

[oliverschmidt]

I suggest to follow-up on that in P2P email. My address is given on https://github.com/oliverschmidt - if you write me I'll have your address too...

I'm not quite ready to do that just yet [...]

Not ready to do what? I just proposed a little private chat about network file access in contrast to network drive access ;-)

If you use FaceySpace much [...]

Nope. MIGA.

Going forward, I'll be reorganizing things into "proper" Debian ways of doing things where possible. [...]

I watched the Kfest 2016 video that shows you explaining your ideas :-)