Exploring Alternatives to Windows/ASCOM...

[sandyshaw]

We had an effort to do something like this a few years ago - ASCOM-X.

The sort of thing we were thinking of was something like this:

• Develop a wire protocol that maps the ASCOM property and method calls and responses to platform agnostic messages on a network.
• Implement handlers for this, both for applications and drivers, on every platform.
• Develop a way for remote devices to be discovered and ideally configured remotely.  This is difficult.

I managed the first and the second on Windows, including a demo application, but made the mistake of using UDP for the transport layer and people couldn't see beyond that to the concept.  I gave up and no one else moved it forwards.  Eros-Lite seems to do much the same thing.  There's no obvious reason why the ASCOM interface should not be mapped onto something that would work with Linux or iOS.

This all means that an ASCOM - or ASCOM like - platform is developed separately on each platform, using the technology that is appropriate for that platform and a common wire protocol.  Windows can stay with COM while Linux uses dlls, or whatever they find works best for them.  This would be LASCOM and iASCOM I suppose.

This looses the concept of one source that runs everywhere but from what I've seen this doesn't work very well for the sort of things that drivers need to do.

Trying to be code compatible would be really difficult, personally I wouldn't go there.

Chris

How about ASCOm as a service, only 19.99 per month.

If that is what you want I can accomodate a subscription plan.

[JamesF]

Bit harsh. I wouldn't say windows is any less arcane - it just hides it better.

I don't see there's much that's more arcane that the WIndows Registry.  I can't stand configuration data that isn't plain text, regardless of what system it's being used on.

James

[sandyshaw]

I don't see there's much that's more arcane that the WIndows Registry.  I can't stand configuration data that isn't plain text, regardless of what system it's being used on.

James

Which is why .Net moves it all to application.exe.config local XML files, welcome to the year 2000.

[NickK]

How about ASCOm as a service, only 19.99 per month.

If that is what you want I can accomodate a subscription plan.

12*20 = 240 a year.. I can count the number of times I managed to get out in the last year on both hands. I think it comes down to perception of value - ASCOM et al are seen as technical enablers; the real value is can I do (see targets, image targets) regardless of the technology.

At 240 a year.. remote telescopes would be a major competitor.. which is what I believe you may have been hinting at.

From experience - writing a framework such as ASCOM is possible with a few people, writing and maintaining drivers over multiple platforms is where the effort require blossoms.. especially in the end people expect the software/driver to "just work" on whatever they have.

[sandyshaw]

Which is why .Net moves it all to application.exe.config local XML files, welcome to the year 2000.

Also, Windows has SxS, Side by Side versioning even of unmanaged DLL's, even for MFC applications now windows has SxS as well as versioning in .Net assemblies.

[tekkydave]

I think the principle of it being network-based is the best model. Each os has it's own way of implementing services but they can all communicate via tcp/ip. Maybe we can persuade manufacturers to build ip capabilities into their gear or there could be a good opportunity for 3rd party adapters. We connect stuff together with serial and usb cables at the moment so replacing them with network cables or even wifi would not be a big step. The platform on each os would have to be platform-specific but as you say there is no way round that.

[sandyshaw]

I think the principle of it being network-based is the best model. Each os has it's own way of implementing services but they can all communicate via tcp/ip. Maybe we can persuade manufacturers to build ip capabilities into their gear or there could be a good opportunity for 3rd party adapters. We connect stuff together with serial and usb cables at the moment so replacing them with network cables or even wifi would not be a big step. The platform on each os would have to be platform-specific but as you say there is no way round that.

Yeah serial, that is something that Skywatcher is serverly lacking.. USB.

[JamesF]

Also, Windows has SxS, Side by Side versioning even of unmanaged DLL's, even for MFC applications now windows has SxS as well as versioning in .Net assemblies.

Like UNIX had shared library versioning in the 1980s?

James

[sandyshaw]

Like UNIX had shared library versioning in the 1980s?

James

And did Linux carry this over?

[tekkydave]

12*20 = 240 a year.. I can count the number of times I managed to get out in the last year on both hands. I think it comes down to perception of value - ASCOM et al are seen as technical enablers; the real value is can I do (see targets, image targets) regardless of the technology.

At 240 a year.. remote telescopes would be a major competitor.. which is what I believe you may have been hinting at.

From experience - writing a framework such as ASCOM is possible with a few people, writing and maintaining drivers over multiple platforms is where the effort require blossoms.. especially in the end people expect the software/driver to "just work" on whatever they have.

I don't disagree with any of that. It would be nice if it "just worked" on my os of choice though.

[Chris Rowland]

Which is why .Net moves it all to application.exe.config local XML files, welcome to the year 2000.

ASCOM tried moving the data out of the registry a few years ago.  It was a support disaster because quite a few drivers and applications were using "our" area in the registry independently of the tools we provided.  We ended up moving back.

Chris

[sandyshaw]

ASCOM tried moving the data out of the registry a few years ago.  It was a support disaster because quite a few drivers and applications were using "our" area in the registry independently of the tools we provided.  We ended up moving back.

Chris

That's not window's fault, that is the drivers and applicaitons fault.

[sandyshaw]

That's not window's fault, that is the drivers and applicaitons fault.

Further, the fact that applications and drivers implementation is VISIBLLY affacting ASCOM breaks the best practice of encapsulation and abstracting what varies.

[NickK]

I think the principle of it being network-based is the best model. Each os has it's own way of implementing services but they can all communicate via tcp/ip. Maybe we can persuade manufacturers to build ip capabilities into their gear or there could be a good opportunity for 3rd party adapters. We connect stuff together with serial and usb cables at the moment so replacing them with network cables or even wifi would not be a big step. The platform on each os would have to be platform-specific but as you say there is no way round that.

Hmm TCP/IP addition to products:

a) increases unit cost 

adds latency difficulties as TCP/IP isn't a realtime protocol, which means devices have to be smarter and thus more expensive (rather than controlling using the driver etc).

[JamesF]

And did Linux carry this over?

It did.

James

[sandyshaw]

Hmm TCP/IP addition to products:

a) increases unit cost 

adds latency difficulties as TCP/IP isn't a realtime protocol, which means devices have to be smarter and thus more expensive (rather than controlling using the driver etc).

Google protocol buffers, very fast and low network footprint, suitable for high frequancy mobile applications.  In short, it is a back to binary payloads with human readable debugging.

If you want Real time protocols, RTTP is for that, usually used for streaming media.

[tekkydave]

ASCOM tried moving the data out of the registry a few years ago.  It was a support disaster because quite a few drivers and applications were using "our" area in the registry independently of the tools we provided.  We ended up moving back.

Chris

In principle the windows registry is a good idea. It makes sense to keep all the config data in one place rather than spread all over the file system. The problems seem to be caused by poorly behaved applications.

[sandyshaw]

In principle the windows registry is a good idea. It makes sense to keep all the config data in one place rather than spread all over the file system. The problems seem to be caused by poorly behaved applications.

Actually it is not, it was admitted long ago and why they moved back to local config files with .net (aka, .ini files).

[sandyshaw]

Actually it is not, it was admitted long ago and why they moved back to local config files with .net (aka, .ini files).

They even went through a few varaiations on registering COM modules, self registering, central registering et al, they couldn't decide

[JamesF]

In principle the windows registry is a good idea. It makes sense to keep all the config data in one place rather than spread all over the file system. The problems seem to be caused by poorly behaved applications.

"Spreading stuff all over the filesystem" is definitely a bad idea, but I'm not convinced that there's a genuine paradigm difference between using one file (or a small number of files) in a well-defined location and using the registry.  Either way you look it it, it's effectively a database.  It's just the addressing mechanism that's different

James

[sandyshaw]

"Spreading stuff all over the filesystem" is definitely a bad idea, but I'm not convinced that there's a genuine paradigm difference between using one file (or a small number of files) in a well-defined location and using the registry.  Either way you look it it, it's effectively a database.  It's just the addressing mechanism that's different

James

Not if you want app portability.

Keeping things local to where it matters is not a bad idea.

[Chris Rowland]

Further, the fact that applications and drivers implementation is VISIBLLY affacting ASCOM breaks the best practice of encapsulation and abstracting what varies.

Sure, but we were the ones with users blaming ASCOM for their system not working.  The driver and/or application developers were long gone.

We weren't interested in some programming practice being correct, we weren't interested in allocating blame, we were interested in users being able to use their systems.  So we applied a pragmatic solution.

Chris

[sandyshaw]

Sure, but we were the ones with users blaming ASCOM for their system not working.  The driver and/or application developers were long gone.

We weren't interested in some programming practice being correct, we weren't interested in allocating blame, we were interested in users being able to use their systems.  So we applied a pragmatic solution.

Chris

Well if the app / driver is not supported, you are out of luck.

Replace it, obviously it will become a bigger problem later too.

[JamesF]

Replace it, obviously it will become a bigger problem later too.

I think you have a volunteer, Chris

James

[sandyshaw]

I think you have a volunteer, Chris

James

Have you asked them for the source to continue supporting of it?