Eliminate Print Servers: go LANless?
-
@johnhooks said:
Yes but if you're not a developer, who has the ability to spend possibly weeks learning their API and building an application to do this?
.Should be the opposite. API should take less effort than having to code "under the hood" and learn their database and relationships and figure out what correct data is and isn't. ODBC means you have to do ALL the work rather than accepting the resulting data. For the reason you mention, ODBC has been replaced for two decades as how to handle these situations.
-
@johnhooks said:
I can't believe that's archaic at all. It is still used all the time by tons of people.
So Windows 98 isn't archaic? You are actually saying that you don't believe that client/server programming isn't archaic? We were laughing any anyone doing this by the late 1990s. It's as archaic as it gets in IT. Unless maybe you are running this on your PDP-11.
-
@johnhooks said:
End users aren't seeing any database details. You write the query and set the report up, they just type in a name and date or whatever info is required.
YOU are the end user here. This is not your database or your application.
-
@scottalanmiller said:
@johnhooks said:
I can't believe that's archaic at all. It is still used all the time by tons of people.
So Windows 98 isn't archaic? You are actually saying that you don't believe that client/server programming isn't archaic? We were laughing any anyone doing this by the late 1990s. It's as archaic as it gets in IT. Unless maybe you are running this on your PDP-11.
Who was laughing at people doing this? You were laughing at people using a technology in the 90's that was newly developed in the 90's?
How is this https://developer.spotify.com/web-api/endpoint-reference/ any easier to learn than a database structure? And that's only for Artists, tracks, playlists, and profiles.
API should take less effort than having to code "under the hood" and learn their database and relationships and figure out what correct data is and isn't
There is no programming here. It's SQL query generation and then repeated with a report that spits out a PDF or whatever you want.
-
@johnhooks this is more of Scott's fantasy island thing. I only argue with him on these silly statements when I am bored.
-
The core of what is printed is information from the other systems that we have no APIs into. All we have is the ability to print the information, either to paper or PDF.
That information can be saved into the current EHR. The problem with this information is that it's non searchable at all, it's just an image. My EHR does not have any OCR ability with regards to these PDFs - they are just dumb pictures basically.
-
@johnhooks said:
Who was laughing at people doing this? You were laughing at people using a technology in the 90's that was newly developed in the 90's?
Client / Server architecture goes back to the 1970s. It was already very old in the 1990s and widely known to be a major problem with security, safety, scalability, etc. Developers were laughing at people trying to implement things from decades past in new code.
-
@johnhooks said:
How is this https://developer.spotify.com/web-api/endpoint-reference/ any easier to learn than a database structure? And that's only for Artists, tracks, playlists, and profiles.
That's failed logic. That you feel that "someone" has made a complicated API has no bearing or relevance to the fact that an API is the right way or easier potential way to work. The database behind that API could be any degree of complex that you do not anticipate as well. You are using the assumption of an easy database structure with a real world API. Even this isn't an example of an API that is harder, only an API you feel is hard. So it doesn't suggest that what you propose is true. At best it is an example of a bad API.
-
@johnhooks said:
There is no programming here. It's SQL query generation and then repeated with a report that spits out a PDF or whatever you want.
Who is generating the query? How do you get a query without someone writing it? I can pull data from an API without code, too, in the same manner.
-
@scottalanmiller said:
Best technique is, of course, to get rid of printing
It's amazing to me how people get so "attached" to printing (almost like it's a measure of self worth)
I mean, people freak out if they can't print! -
@scottalanmiller said:
@johnhooks said:
Who was laughing at people doing this? You were laughing at people using a technology in the 90's that was newly developed in the 90's?
Client / Server architecture goes back to the 1970s. It was already very old in the 1990s and widely known to be a major problem with security, safety, scalability, etc. Developers were laughing at people trying to implement things from decades past in new code.
Developers at what company? ODBC is still used today.
-
@johnhooks said:
Who was laughing at people doing this?
I know, for example, that NTG was confident that we were getting development work from UPitt in the late 1990s because we were proposing using 1990s architectures instead of 1970s and 1980s architectures that they had been using. That was the 1990s and we had been doing that kind of work for years and we were hardly pioneers, we were pretty much development newbies. By the time that we were learning modern architectures in the later 1990s the idea that n-tier had completely displaced client/server and that c/s was a ridiculous idea whose time had come and gone was passé to even discuss. By the late 1990s, that c/s was an idea that should never be implemented on new systems was roughly like deploying physical servers today instead of virtualizing. Sure, lots of people who don't know what they are doing and are totally out of touch still do it, but we all know it is ridiculous for new systems.
-
@scottalanmiller said:
@johnhooks said:
How is this https://developer.spotify.com/web-api/endpoint-reference/ any easier to learn than a database structure? And that's only for Artists, tracks, playlists, and profiles.
That's failed logic. That you feel that "someone" has made a complicated API has no bearing or relevance to the fact that an API is the right way or easier potential way to work. The database behind that API could be any degree of complex that you do not anticipate as well. You are using the assumption of an easy database structure with a real world API. Even this isn't an example of an API that is harder, only an API you feel is hard. So it doesn't suggest that what you propose is true. At best it is an example of a bad API.
And that's an API written to be used by anyone. It's not an API written by an EMR company that doesn't have everyone looking at it. That would almost always be much more complex. Especially with all of the data that's contained there.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
Who was laughing at people doing this? You were laughing at people using a technology in the 90's that was newly developed in the 90's?
Client / Server architecture goes back to the 1970s. It was already very old in the 1990s and widely known to be a major problem with security, safety, scalability, etc. Developers were laughing at people trying to implement things from decades past in new code.
Developers at what company? ODBC is still used today.
Sure, and I have no idea why you are talking about it. ODBC isn't the issue, client/server design is. Don't use ODBC as an end user.
-
@scottalanmiller said:
@johnhooks said:
There is no programming here. It's SQL query generation and then repeated with a report that spits out a PDF or whatever you want.
Who is generating the query? How do you get a query without someone writing it? I can pull data from an API without code, too, in the same manner.
What applications can you use that generate API code for you? I can think of quite a few that will generate SQL for you based off of what you tell it.
-
@johnhooks said:
And that's an API written to be used by anyone. It's not an API written by an EMR company that doesn't have everyone looking at it. That would almost always be much more complex. Especially with all of the data that's contained there.
Why would it be assumed to be more complex? I use APIs every day that are not designed to be used by people (ML's for example, SW's, etc.) and they are dead simple. Your logic doesn't flow. Yes, the EMR company might screw up the API, but it might be super simple too (or not exist if they are total crap software.) But you are taking one bad API example from a company that makes consumer software for music, making assumptions about the simplicity of their database and using that unfounded combination of assumed easy relational database, combining it with assumed complex API and using it to derive the complexity of unrelated databases and APIs on which it has no bearing.
You might as well say that Microsoft Word is complex because Spotify is hard to use. What does one have to do with the other?
-
@johnhooks said:
What applications can you use that generate API code for you? I can think of quite a few that will generate SQL for you based off of what you tell it.
I'm not sure what you are asking. API is a generic concept, SQL is a specific language. This isn't comparable.
-
@scottalanmiller said:
@johnhooks said:
What applications can you use that generate API code for you? I can think of quite a few that will generate SQL for you based off of what you tell it.
I'm not sure what you are asking. API is a generic concept, SQL is a specific language. This isn't comparable.
Because you said this?
Who is generating the query? How do you get a query without someone writing it?
You don't have to write the query. It's generated for you. I'm saying, give me software that can get info with an API with that amount of simplicity.
-
Even if you were to use raw SQL to consume a remote database, you would still want to create your own API from that, right? So you are just doing their work for them. You would not consumer the SQL results directly, right?
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
What applications can you use that generate API code for you? I can think of quite a few that will generate SQL for you based off of what you tell it.
I'm not sure what you are asking. API is a generic concept, SQL is a specific language. This isn't comparable.
Because you said this?
Who is generating the query? How do you get a query without someone writing it?
You don't have to write the query. It's generated for you. I'm saying, give me software that can get info with an API with that amount of simplicity.
APIs are often so simple that I don't even need anything but a web browser to consume them. Show me ODBC that doesn't need ANY code, generated or otherwise. Good APIs are so simple that I can't believe we have anything to discuss. I consume APIs by hand every day. I certainly don't do that with SQL or ODBC. I also don't do it without knowing tons of details about the database.
How do you get information out of a foreign database without knowing the structure and how the tables and data relate to one another? Even a SQL generator requires you to know more information than a good API requires you to know ever.
