Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Alpaca, INDI and INDIGO developers - please take note!

  • Please log in to reply
25 replies to this topic

#1 Chris W

Chris W

    Vostok 1

  • -----
  • topic starter
  • Posts: 185
  • Joined: 05 Jul 2011
  • Loc: Essex, UK

Posted 04 May 2021 - 04:27 AM

This is an appeal to the developers of these individual protocols.

 

Please work together. heart.png

 

In the beginning, the ASCOM collaboration created a unified device interface for the Windows OS. Its impact propelled the industry forward.

 

We now have multiple OSs and an increasing deployment of small powerful PCs that permit users to operate devices from a client PC or tablet. 

 

The aim of Alpaca, INDI and INDIGO are similar, in so much that they allow flexible systems, with different host and client machines, without creating additional complexity for the application and hardware developers. Each group is doing a fantastic job and are generously working to make life easier for a group of users.

 

I'm not a developer but a user and a retired engineering manager. With three standards, however, the burden increases on software and hardware developers, with two potential outcomes; higher R&D costs and prices, or poorer execution with finite resources.

 

I don't care which is 'best', nor should anyone who adds a comment, because the whole point of this thread is an appeal for these good folks to work together and agree on a common approach. I do not know what that looks like but suspect, if it is efficient, there will be casualties rather than be a kludge of all three.

 

ASCOM was/is not perfect, but we live with it. The experience of working with ASCOM devices over the years, however, is a vast and important resource on how things work and, just as significantly, fail. It is shared resources like these that help shape robust protocols.

 

The industry trend is moving towards smaller computing units and alternative OSs and increasing use of WAN/LAN communication between host and client systems.

 

This is a personal perspective. I think we need an approach that reduces complexity, rather than increases it.


Edited by Chris W, 04 May 2021 - 06:28 AM.

  • okiestarman56, astrokeith, poison and 2 others like this

#2 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • Posts: 252
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 05 May 2021 - 12:38 PM

As one of the ASCOM/Alpaca people, I provided an answer to this on the ASCOM/Alpaca list. I understand your plea to  harmonize the various modular system interfacing technologies. 



#3 TelescopeGreg

TelescopeGreg

    Mercury-Atlas

  • -----
  • Posts: 2,966
  • Joined: 16 Jul 2018
  • Loc: Auburn, California, USA

Posted 05 May 2021 - 09:43 PM

"The great thing about standards is that we have so many to choose from.  And if you don't like what what's available, just wait a bit for the next one to come around".    -- Author unknown (at least to me)

 

My take on this whole thing is that I'm perfectly happy using INDI on my Linux systems, and for the short time I used Windows, ASCOM there.  There is no benefit to me to make yet another "standard" way of doing the same set of things all over again.  The various operating system platforms (Windows, Linux, OSX, Android, iStuff) are different enough that "unifying" the astronomy subsystem is hardly noticed.  I use back-slashes on Windows, and forward ones on Linux.  So what?  There is advantage in being multi-lingual, both in society as well as technology.



#4 sbradley07

sbradley07

    Viking 1

  • *****
  • Moderators
  • Posts: 540
  • Joined: 06 Mar 2017
  • Loc: Connecticut

Posted 05 May 2021 - 10:28 PM

In my view, having multiple standards (architectures really) is advantageous to us as end users because it offers choice.  We can pick whatever lane we're comfortable with or what best meets our requirements.  INDI has gotten a lot of people into astrophotography because you can run it on a $50 computer.  A lot of those people weren't Linux gurus, but it's a tinkering hobby to begin with, so the low entry cost necessitated the need to learn a little Linux.  INDI is turning out to be pretty good for ZWO too!  ASCOM has very broad and excellent industry support, but only on (what was for a very long time) the most common computing platform.  Now they're looking to leverage that support to other platforms with Alpaca.  Very good move.  As to the development onus on hardware and software vendors, it isn't really that different with multiple architectures, if at least one of them is open source...which INDI is.  Vendors still for the most part write their own ASCOM drivers, but INDI drivers are mostly developed by the open source community. 

 

All this means is that we have an extensive host of options to choose from to capture awesome images. 


  • mikefulb likes this

#5 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • Posts: 252
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 06 May 2021 - 07:47 AM

@TelescopeGreg - A thoroughly practical and  reasonable view. Us ASCOM folks responded to repeated requests from  many to extend the reach of our interfaces (the nouns, verbs, etc.) beyond Windows, and the result is Alpaca and the 2-way compatibility between it and classic ASCOM. I’m obliged to repeat ad nauseum that Alpaca is 100% independent of Windows.



#6 astrokeith

astrokeith

    Ranger 4

  • -----
  • Posts: 304
  • Joined: 14 Mar 2010
  • Loc: Surrey, UK

Posted 06 May 2021 - 08:13 AM

 I’m obliged to repeat ad nauseum that Alpaca is 100% independent of Windows.

Then I suspect the messaging needs to change on the Alpaca website. I went there to see what it was all about, and a) found it confusing, and b) had a feeling that a Windows machine was still needed. I'm quite tech and computer savvy, so I dont think its just me!


  • rpineau, sbradley07 and Bobo666 like this

#7 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • Posts: 252
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 06 May 2021 - 08:51 AM

@astrokeith - Thank you very much for your feedback. Is it this diagram?

 

58B5E5E3-1CC0-40D4-B2CB-A7BC407F375E.png

 

Or is it the wording in the Introduction to Alpaca?

 

We tried to  show that it is an extension beyond Windows, with a two-way middleware component providing transparent interconnectivity, and also independent (the Alpaca to Alpaca line). Let me talk this over with the author of that diagram and see if we can produce something better. This is a challenge. You may note the “Developers” notation on that info already.  Interfacing in a modular system, and its key role in the success or failure of same, is neither well known nor appreciated by many developers. 

 

Thank you again —

 

  — Bob


Edited by Bob Denny, 06 May 2021 - 08:52 AM.


#8 Fivel

Fivel

    Vostok 1

  • *****
  • Posts: 187
  • Joined: 14 Nov 2013

Posted 06 May 2021 - 09:58 AM

Hello to all and thank you for this discussion.

I also have difficulty determining if I can use ALPCA in my system.

The diagrams and text still allude to the necessity of a Windows computer at the telescope.

My setup is:

1.Mac  Mini at the scope with USB hub and Gigabit Ethernet switch.

2. Interconnection over Cat5e cable to my office

3. Another Mac ini in my office at the other end of the Cat5e/Gigabit Ethernet switch.

4. There is no network or IP use here, I simply use the Mac screen sharing using vnc between the computers.

My goal is to use some ALPACA drivers at the scope, and remotely control all of my observatory equipment, via the Mac in my office. So my basic questions are as follows.

1. Will this be possible without the need for a Windows computer?

2. Whet version of ALPACA do I need on my Mac at the scope?

3. What version of ALPACA do I need on my office Mac?

4. Will this work without having an actual network?

 

Thank you for any clarifications, and for the hard work the team has been putting into the ALPACA platform.

 

Stay well and have clear skies.

 

Fivel

 



#9 airscottdenning

airscottdenning

    Viking 1

  • *****
  • Posts: 563
  • Joined: 22 Aug 2008
  • Loc: Colorado

Posted 06 May 2021 - 10:03 AM

INDI and INDIGO are interoperable.

 

When will ALPACA become compatible?



#10 astrokeith

astrokeith

    Ranger 4

  • -----
  • Posts: 304
  • Joined: 14 Mar 2010
  • Loc: Surrey, UK

Posted 06 May 2021 - 11:16 AM

@astrokeith - Thank you very much for your feedback. Is it this diagram?

 

attachicon.gif58B5E5E3-1CC0-40D4-B2CB-A7BC407F375E.png

 

Or is it the wording in the Introduction to Alpaca?

 

We tried to  show that it is an extension beyond Windows, with a two-way middleware component providing transparent interconnectivity, and also independent (the Alpaca to Alpaca line). Let me talk this over with the author of that diagram and see if we can produce something better. This is a challenge. You may note the “Developers” notation on that info already.  Interfacing in a modular system, and its key role in the success or failure of same, is neither well known nor appreciated by many developers. 

 

Thank you again —

 

  — Bob

Hi, yes that diagram doesnt help much. The only server shown clearly is Windows.

 

On the Alpaca FAQ section of the users guide, all six bullets mention and even mostly underline 'Windows' in the text.

 

The diagrams and text have been produced by someone who is developing the system. It needs explanations for real users, who need clear, non-jargon loaded examples.  


  • Der_Pit likes this

#11 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • Posts: 252
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 07 May 2021 - 02:24 PM

Keith, thanks again for the feedback.

 

 

Hi, yes that diagram doesnt help much. The only server shown clearly is Windows.

The "server"  is the middleware that connects Alpaca and ASCOM - ASCOM Remote. Neither ASCOM on Windows nor Alpaca need that component. Neither of  the two need a "server". They are peer-to-peer (client to driver). I'll see about making that more clear. 

 

 

On the Alpaca FAQ section of the users guide, all six bullets mention and even mostly underline 'Windows' in the text.

Do you mean the Alpaca section of this FAQ?

 

If so, then the info we have needs to evolve. Back when it was written those questions about breaking compatibility were common concerns.

 

 

The diagrams and text have been produced by someone who is developing the system. It needs explanations for real users, who need clear, non-jargon loaded examples.

If you  are referring to this info on the ASCOM web site, then indeed this is for developers and necessarily needs to explain design and implementation in a technical framework. But we try to make that clear at the outset:

 

Snap1.jpg

 

And the confusing diagram is preceded by what should be a clear statement about not needing Windows. Still You're right that the diagram needs work

 

Snap2.jpg

 

Thanks again. I have saved this discussion for consideration and improvement of the info on the web site. If you have a few moments to help us from the outside to explain modular systems, driver/client,  and interfacing compatibility in non-jargon way it could really help.


Edited by Bob Denny, 07 May 2021 - 02:26 PM.


#12 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • Posts: 252
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 07 May 2021 - 04:57 PM

INDI and INDIGO are interoperable.

 

When will ALPACA become compatible?

ASCOM and Alpaca are compatible, if that's what you mean.



#13 poison

poison

    Lift Off

  • -----
  • Posts: 13
  • Joined: 12 Feb 2012

Posted 08 May 2021 - 04:14 AM

I‘ll Guess what the OP is trying to say is „Choose one of the existing standards make this the gold standard and trash the remaining ones“. And I second that.

 

Beside of INDI and the other’s, there’s also TheSkx X with their X2 „standard“. 

As a Mac user I‘ll use INDI with KStars and INDIGO with their AstroImager. 

 

I already asked why everyone (INDI/INDIGO) is working on their own and not working together. 
The answers where similar: Everyone wants to keep their „baby“. This also behaves to Bisque. 

 

I also take a look at Alpaca however it is so **** technical like its 1990 again.

Nowadays I don’t want to be flooded with diagrams or detailed technical background as a user.
I want to download, install and start without fiddling around.

 

Taking a look at the FAQ makes me shiver, as I don’t understand what is going on here. 
Alpaca says it is for all systems but in the FAQs there is only Ascom stuff I don’t understand as a Mac user. 
 

That said I also wished that there was only one standard for all operating systems.



#14 Patrick Chevalley

Patrick Chevalley

    Vostok 1

  • -----
  • Vendors
  • Posts: 159
  • Joined: 04 Jul 2017

Posted 08 May 2021 - 07:47 AM

Hi,

 

Just to give my point as a client application developer.

For me, having to work with different standard is not a real issue, but please refrain to invent one more https://xkcd.com/927/

 

The most important is the end user can run the application on the platform he want, and find the driver it need for its equipment on the platform he want to connect it. The fact this driver use one protocol or another must not prevent the use with the application.

 

After that it is to the client application to adapt to support this different possibility.

In fact only two main variant because ASCOM/Alpaca logic is the same (only transport is different) and Indigo can be seen as a different implementation of the INDI protocol.

 

For the client application, the developer write a camera class for example, this can later be specialized as an ASCOM camera class and an INDI camera class that contain the protocol specific code.

It is always much more easy to implement ASCOM and INDI in the application than zillion of device specific proprietary protocol that each require a different trick to make it work.

 

Now unifying ASCOM and INDI look difficult. Not only because of the different verb for the equivalent functionality, but mainly because of the different way they work.

With ASCOM you query the driver when you want to know a property, for example what is the current sensor temperature.

But with INDI this device pooling is done by the server that send a message to the application every time the sensor temperature change.

This make a "bridge" between the two not impossible but to require some complex logic.

 


  • poison and Der_Pit like this

#15 WadeH237

WadeH237

    Fly Me to the Moon

  • *****
  • Posts: 7,059
  • Joined: 24 Feb 2007
  • Loc: Ellensburg, WA

Posted 08 May 2021 - 08:35 AM

I also take a look at Alpaca however it is so **** technical like its 1990 again.

Nowadays I don’t want to be flooded with diagrams or detailed technical background as a user.
I want to download, install and start without fiddling around.

 

Taking a look at the FAQ makes me shiver, as I don’t understand what is going on here. 

I don't think that you are in the audience for which these docs are intended.  As a user, you shouldn't care about any of this.  You just want your stuff to work - and that is a perfectly reasonable expectation.

 

If I understand Alpaca correctly, it's just a transport layer.  You can have a device with INDI drivers.  You can have a device with ASCOM drivers.  Or you can have a device with proprietary drivers.  And you can use Windows, Linux or Mac.  As long as the drivers have a thin layer to "speak" Alpaca, they can all talk to each other seamlessly.  And since Alpaca is built on top of a network protocol, it doesn't even matter if the devices are on the same physical machine or not.  You can have a weather station running on an outbuilding, with a Raspberry Pi running the mount and camera, with automation software running on a completely different machine in the house, and they'll all work together as one system.

 

It's actually pretty cool.  But the existing documentation and such is intended for a developer audience to build those thin layers on top of whatever drivers.  Like anything else - especially when there are lots of different players, with different agendas and politics - it takes time.


Edited by WadeH237, 08 May 2021 - 08:35 AM.

  • poison likes this

#16 MartinMeredith

MartinMeredith

    Viking 1

  • *****
  • Posts: 673
  • Joined: 01 Feb 2015

Posted 08 May 2021 - 11:17 AM

Rather than bridging ASCOM and INDI, the alternative is to wrap them in a higher-level OS-independent API. I guess that is what in practice Patrick is describing and it is what I do and what everyone who cares enough to develop platform-independent applications is forced to do. So we each have our own high-level wrappers..... but what a crazy duplication of effort!

 

As a programmer all I actually care about is issuing a high-level command like "slew to this position" or "take a 3s exposure" or "change to filter at position 3" (along with a bunch of optional parameters and callbacks to call on completion or failure) without having to delve into either ASCOM and INDI. There is an existence proof that these commands are implementable in ASCOM and INDI and if I'm developing for multiple OSs then I really shouldn't have to care about how they are actually achieved. 

 

 

As a direct analogy, when I develop OS-independent programs (in Python in my case) that need to bring up a file browser, I use the same OS-independent code and rely on a well-implemented library to ensure that a native filebrowser is brought up on each platform. Another analogy: when I want to talk to a USB-device I use a well-iimplemented platform-independent library to do so. That is what is lacking for astro devices.

 

It isn't that client developers are unable to get their heads around ASCOM and INDI etc. Its just that time spent reinventing that particular wheel is time lost developing interesting and novel and innovative astro software. 

 

Martin



#17 WadeH237

WadeH237

    Fly Me to the Moon

  • *****
  • Posts: 7,059
  • Joined: 24 Feb 2007
  • Loc: Ellensburg, WA

Posted 08 May 2021 - 12:21 PM

As a direct analogy, when I develop OS-independent programs (in Python in my case) that need to bring up a file browser, I use the same OS-independent code and rely on a well-implemented library to ensure that a native filebrowser is brought up on each platform. Another analogy: when I want to talk to a USB-device I use a well-iimplemented platform-independent library to do so. That is what is lacking for astro devices.

 

It isn't that client developers are unable to get their heads around ASCOM and INDI etc. Its just that time spent reinventing that particular wheel is time lost developing interesting and novel and innovative astro software. 

Bob can correct me if I am wrong, but I don't think that Alpaca is intended to replace either ASCOM or INDI.

 

I think that the goal is that as an application developer, you can write using the API that you want.  For example, if you want to write to ASCOM (or even just use an ASCOM based application as a user), you can do so.  Alpaca makes it so that the ASCOM software can take the "slew to this position" command and translate it to an Alpaca message and then send it to the device.  Let's say that the mount is using an INDI driver, running on another machine, say a Mac or Linux box.  The Alpaca layer would transmit the message, and then the Alpaca layer on the remote machine would translate the message to an INDI command to slew the mount.  This would all be transparent from your perspective.  You wouldn't even need to know that the mount was controlled by an INDI driver on another machine.

 

And similarly, if you wanted to write to INDI, the whole thing would work the same way, allowing control of ASCOM devices without your needing to know anything about ASCOM.

 

Of course, nothing prevents device driver writers from simply writing a native Alpaca driver that's not wrapping another, native API.

 

If I've got this right, I personally think that it's a great idea.  It'd be a whole lot harder to get everyone to agree on a single API as you describe.



#18 TelescopeGreg

TelescopeGreg

    Mercury-Atlas

  • -----
  • Posts: 2,966
  • Joined: 16 Jul 2018
  • Loc: Auburn, California, USA

Posted 08 May 2021 - 12:57 PM

And the confusing diagram is preceded by what should be a clear statement about not needing Windows. Still You're right that the diagram needs work

 

attachicon.gifSnap2.jpg

 

As I see it, the big thing Alpaca does is to bring remote operation to ASCOM.  But, that's already present in INDI, a feature that is not brought out in the diagram.  I could argue that what is needed isn't Alpaca, but rather reviving the port of INDI to Windows.

 

I asked on another thread last year something to the effect of "If I'm using INDI on my Linux system, what is the advantage of moving to Alpaca?"  Telling was the answer:  "Nothing."

 

If nothing else, in the interest of balanced reporting, shouldn't the diagram include the remote operation provided by INDI?
 



#19 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • Posts: 252
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 08 May 2021 - 03:24 PM

My goodness there are so many different interpretations of what Alpaca is. Most of them are wrong, owing to trying to apply current knowledge of other standards as a framework. For example:

 

 

If I understand Alpaca correctly, it's just a transport layer.

Far from it. It is a set of interfaces implemented as REST endpoints with the same names and functions as the corresponding ASCOM interface members. Alpaca has a Dome.OpenShutter(), and ASCOM has a Dome.OpenShutter(). No language specific libraries, no servers needed for cross platform, and 20 years of proven suitability of the nouns/verbs for astronomical applications. 

 

We're not in a position to engage in a standards war and will not do so. The level of understanding of Alpaca and ASCOM here is a tad bit thin. I'd rather not alienate some of you with more corrections and clarifications. I feel bad enough posting the above correction. Anyone with the time can get it. And it is of course "technical" with "jargon". The developers of apps and devices are responsible for bringing "simple" and "intuitive" to users. I will repeat what I posted in the ASCOM Developer list in response to the original poster @Chris W:

 

--- snip ---

 

We can't stop others from inventing their own protocols and standards, nor can we kill off other solutions that exist in other ecosystems. All we can hope for is that eventually, like Betamax vs VHS there will be one that snowballs. Of course we hope it's ours :-)  If you look at history, the ones that come out of specific applications, and are pushed as a standard, have less of a chance. Our approach is to smother both application and device developers with tools, libraries, templates, guidance, and help. There is a lot of stuff there and more coming shortly. See Projects in Progress (these have a short time horizon) as well as the large amount of info and tools for developers. The video on the latter page is a live stream that came out of Woodland Hills Camera and Telescope on which I appear and give equipment and app developers a briefing. It's long(!) but this stuff ain't trivial. It is, however, really vital to the health of the business.  All we can do is put forth our best efforts and make **** sure we're headed the right way (see the 2019 survey).

 

--- snip ---


Edited by Bob Denny, 08 May 2021 - 10:11 PM.


#20 Patrick Chevalley

Patrick Chevalley

    Vostok 1

  • -----
  • Vendors
  • Posts: 159
  • Joined: 04 Jul 2017

Posted 09 May 2021 - 02:46 AM

Rather than bridging ASCOM and INDI, the alternative is to wrap them in a higher-level OS-independent API. I guess that is what in practice Patrick is describing and it is what I do and what everyone who cares enough to develop platform-independent applications is forced to do. So we each have our own high-level wrappers..... but what a crazy duplication of effort!

Martin,

 

Yes this is what I think is the only possibility to develop multi-standard application. This multiple standard exist, are of large use, and we have to live with.

Because of the fundamental difference between this standards, trying to write an universal wrapper will result in crippled functionality because this can safely use only the common part of all the different standard.

The advantage to do it at the application level is you can implement only what is need for the application in a way that is optimized for the application use.

For example ASCOM define a FocusOffsets property for the filter wheel, but there is no INDI equivalent, so with INDI you have to manage the filter offset list in the application.

 

I develop mainly on Linux and now when I add a new functionality to one of my application I always start with the Alpaca interface to take advantage of its well defined specification. Testing is easy and reliable by connecting to a virtual machine running the ASCOM simulators.

Then making it work with native ASCOM is as easy as replacing the REST call by the equivalent native COM call. And this work immediately because the behavior is the same.

After that I look how this can be done with INDI using the available properties. This is always possible because this is finally the same low level protocol or manufacturer library that are used by the driver to access the same devices.


Edited by Patrick Chevalley, 09 May 2021 - 03:20 AM.


#21 poison

poison

    Lift Off

  • -----
  • Posts: 13
  • Joined: 12 Feb 2012

Posted 09 May 2021 - 04:50 AM

I don't think that you are in the audience for which these docs are intended.  As a user, you shouldn't care about any of this.  You just want your stuff to work - and that is a perfectly reasonable expectation.

Well, there are also enduser FAQ that explain the Cross-Platform aspect. 
However, the whole FAQ is ASCOM specific telling Alpaca will work on iOS, Mac… only in a side note under „What is Ascom Alpaca“.

 

All FAQs below are just „Will Alpaca change or break my existing ASCOM…..“. That makes me scratch my head. Where is the Cross-Platform aspect?

 

So I still have no clue what’s going on with Alpaca as a non Windows/Ascom user. ‍♂
https://ascom-standa.../FAQs/Index.htm

 

But that’s not much of a problem, because I have INDI and I still hope this will become the VHS standard in Astronomy.


Edited by poison, 09 May 2021 - 04:51 AM.

  • Bobo666 likes this

#22 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • Posts: 252
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 09 May 2021 - 05:00 AM

@poison I appreciate that feedback. I did mention that the Alpaca section of the FAQ needs refreshing from a couple of years ago where the main concerns were breaking changes and cross-compatibility with existing Windows software. Note that the FAQ also covers Windows ASCOM, followed by Alpaca. 

 

@Patrick Chevalley thanks for that. Note that the first listed Project in Progress is:

 

A single cross-platform executable which will implement native Alpaca simulators for all device types. The simulator suite will run on Linux, Mac, and Windows. Each simulator will be a "reference implementation" of its device type. This means that the behavior of the simulator may be considered "correct" for each operation (though the documentation is always the primary reference for "correct"). Of course the Alpaca simulators may be reached from any ASCOM/COM compatible program on Windows which uses the Chooser and its new automatic COM to Alpaca gateway.

 

This is just about finished. I'll let the author Daniel Van Noord know that you would be a good tester!!


  • poison likes this

#23 Patrick Chevalley

Patrick Chevalley

    Vostok 1

  • -----
  • Vendors
  • Posts: 159
  • Joined: 04 Jul 2017

Posted 09 May 2021 - 09:01 AM

Bob,

 

This project look very interesting to help with Alpaca application development, I will be happy to make some testing.

This is also a great way to demonstrate that Alpaca don't need Windows!


  • Bob Denny likes this

#24 WadeH237

WadeH237

    Fly Me to the Moon

  • *****
  • Posts: 7,059
  • Joined: 24 Feb 2007
  • Loc: Ellensburg, WA

Posted 09 May 2021 - 09:19 AM

I feel bad enough posting the above correction. 

That was my text that you corrected.

 

Please do not feel bad about it at all!  You and I sat down at the last AIC and spoke about Alpaca for a while, and apparently I came away with a misunderstanding. The last thing that I want to do, is to mischaracterize it, so please always feel free to comment on anything that I say.

 

-Wade


  • Bob Denny likes this

#25 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • Posts: 252
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 09 May 2021 - 10:25 PM

That was my text that you corrected.

 

Please do not feel bad about it at all!  You and I sat down at the last AIC and spoke about Alpaca for a while, and apparently I came away with a misunderstanding. The last thing that I want to do, is to mischaracterize it, so please always feel free to comment on anything that I say.

 

-Wade

Oh man @WadeH237 I do appreciate that. The level at which modular systems operate and interface is what I would call "exotic". It is a subtle and oh so important aspect of modern system engineering. I try but I'm too **** close. I totally get why people get confused or misunderstand. Thank you so much for following up. If you'd like to chat live I'm good with it. That applies to anyone else with a sincere desire to understand what this is all about. I am a professional interface negotiator (dating from the old aerospace days) so I've been in the trenches.

 

Again I am not into a standards war. I went through the UUCP vs SMTP vs OSI X.400 wars back in the 1970s. I was banned from speaking at the (then) Electronic Mail Association after twice publicly speaking out against X.400, a protocol in which the European PTTs were heavily invested. It was a loser from the start - invented as "design and decree" by European academics, as were the lower level OSI protocols that were supposed to replace TCP/IP. Interesting times. The whole family died after consuming countless millions from companies which believed the narrative without proof of concept in practice or proof of scalability. The US company OSIWare (El Segundo CA, 1992) is but one example. 

 

I'm available at +1 480 396 9700 during business hours. If I'm head-down software developing or helping a customer I won't pick up. Please leave voice mail, I promise to get back to you ASAP.




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics