Eliminate Print Servers: go LANless?
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
So you're saying it's easier to hand code a whole application to pull the info via an API, and then make your application create reports based off that info.
We can't just make a report here, we need to combine the data from multiple sources into a single thing. This is a rather complex thing, you can't just point some database tool at it and hope to get results.
And as I said above, you don't know that the database can even use ODBC or SQL. Do your tools handle situations where that stuff doesn't even exist?
It's not complex at all. It's drag and drop the attributes you want from the DB.
Again... an assumption you can't make. You are assuming that your database is simple AND relational and assuming that the API is complex. You have to contrive a situation where someone made a database safe and easy when meant for internal only use but makes the API hard to consume even thought meant for external consumption. Can it happen? Sure. Does it make sense that it will work that way typically? No.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
So you're saying it's easier to hand code a whole application to pull the info via an API, and then make your application create reports based off that info. This versus connecting to the DB and viewing data (since in relational the attributes have to be the same across all the relations) and then just telling your application which attributes to pull info from?
Having done both, I'm totally saying that. And by "hand code", I assume that you mean things like "typing out the query?" What coding do you imagine is needed?
You wouldn't be the only one using this. Are you going to teach everyone that's getting this info how to get it from the API or are you going to "hand code" an application for them to do this?
So you are going to "hand code" and teach them all how to access via ODBC? You haven't given me any reason that makes sense for why this is easier or smarter. The API itself is the tool for making this easier for people. AND it is the tool for making it safe.
-
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
@Dashrender said:
@Jason said:
@Dashrender said:
I've inquire with the powers that be if they would like a print to mobile device like option.
The thinking is... Instead of paper. The document could just be sent to a phone or ipad/android tablet, etc. 99% of the time the look and throw away... This would avoid the waste.
Anyone see a anything like this?
Unlikely. There's a lot to go on in the backend with something like that.
Sure there could be a lot on the backend... But I would think this would be immensely useful. Though I'm not sure how you'd do it in a LANless setup... I suppose with something like ZT it might be easier.
Does ZT work with mobile devices?
Android today, iOS soon.
That's great. Wow.
And of course any Windows mobile device can use it normally.
My question would be how can you use that effectively? Just visibility or can you use it to manage devices?
I don't even know what this question means in relation to the technology mentioned.
I mean what benefit is there to having mobile devices on ZeroTier (a VPN)? I assume to give out updates and for visibility.
I don't know, what caused you to ask if you could put them on the VPN? What do you mean by updates and visibility?
Given your mentioned plans, how about watching Plex from the mobile device or answering phone calls?
Sorry if I'm not being clear, I'm trying. Think WSUS but for phones for management purposes in a company
Can you do this on the LAN already? I'm not aware of a tool for doing this on your network. What are you picturing?
-
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
So you're saying it's easier to hand code a whole application to pull the info via an API, and then make your application create reports based off that info. This versus connecting to the DB and viewing data (since in relational the attributes have to be the same across all the relations) and then just telling your application which attributes to pull info from?
Having done both, I'm totally saying that. And by "hand code", I assume that you mean things like "typing out the query?" What coding do you imagine is needed?
You wouldn't be the only one using this. Are you going to teach everyone that's getting this info how to get it from the API or are you going to "hand code" an application for them to do this?
So you are going to "hand code" and teach them all how to access via ODBC? You haven't given me any reason that makes sense for why this is easier or smarter. The API itself is the tool for making this easier for people. AND it is the tool for making it safe.
No that's the whole point. There are a ton of applications that will interface via ODBC and let you pretty much drag and drop search boxes, text fields, etc and make reports the same way. Read only via ODBC is perfectly safe. It's fully encrypted from end to end. The same can't be said about the app that's produced if encryption is implemented incorrectly or not at all.
-
@scottalanmiller said:
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
@Dashrender said:
@Jason said:
@Dashrender said:
I've inquire with the powers that be if they would like a print to mobile device like option.
The thinking is... Instead of paper. The document could just be sent to a phone or ipad/android tablet, etc. 99% of the time the look and throw away... This would avoid the waste.
Anyone see a anything like this?
Unlikely. There's a lot to go on in the backend with something like that.
Sure there could be a lot on the backend... But I would think this would be immensely useful. Though I'm not sure how you'd do it in a LANless setup... I suppose with something like ZT it might be easier.
Does ZT work with mobile devices?
Android today, iOS soon.
That's great. Wow.
And of course any Windows mobile device can use it normally.
My question would be how can you use that effectively? Just visibility or can you use it to manage devices?
I don't even know what this question means in relation to the technology mentioned.
I mean what benefit is there to having mobile devices on ZeroTier (a VPN)? I assume to give out updates and for visibility.
I don't know, what caused you to ask if you could put them on the VPN? What do you mean by updates and visibility?
Given your mentioned plans, how about watching Plex from the mobile device or answering phone calls?
Sorry if I'm not being clear, I'm trying. Think WSUS but for phones for management purposes in a company
Can you do this on the LAN already? I'm not aware of a tool for doing this on your network. What are you picturing?
No I can't. I don't really do anything with mobile devices so I figured I'd ask questions. Sorry I'm not making a ton of sense
-
@johnhooks said:
No that's the whole point. There are a ton of applications that will interface via ODBC and let you pretty much drag and drop.
But we've covered why they can't work here, right? So this point is moot. ODBC can be ruled out as technically impossible. So why does it keep getting mentioned? How is this even considered an option?
-
@johnhooks said:
Read only via ODBC is perfectly safe.
How? I explained why it can't be. You can't be sure that the end users are using the relationships correctly, so the data is not reliable.
-
@scottalanmiller said:
@johnhooks said:
No that's the whole point. There are a ton of applications that will interface via ODBC and let you pretty much drag and drop.
But we've covered why they can't work here, right? So this point is moot. ODBC can be ruled out as technically impossible. So why does it keep getting mentioned? How is this even considered an option?
It wasn't ruled out at all. You said they may be using NoSQL (or no database at all), which is unlikely as these types of data stores are usually too complex for that.
-
@johnhooks said:
It's fully encrypted from end to end. The same can't be said about the app that's produced if encryption is implemented incorrectly or not at all.
If you can say it about ODBC you can say it about any connection. If you question if this can be enforced on an API, then any logic used there makes ODBC unsafe in the same way. They are equal in being able to enforce encryption. That's not the concern. It's the integrity of the assembled data that ODBC cannot protect.
-
@johnhooks said:
It wasn't ruled out at all. You said they may be using NoSQL (or no database at all), which is unlikely as these types of data stores are usually too complex for that.
Totally ruled out. Using NoSQL is increasingly common and the use of a single database for huge systems like this is almost never going to happen. That some of the systems use NoSQL or something that cannot use ODBC is an extremely real possibility and increasingly so in the future. That it is unlikely to be the sole datasource is very true, but not relevant.
-
@wirestyle22 said:
No I can't. I don't really do anything with mobile devices so I figured I'd ask questions. Sorry I'm not making a ton of sense
VPN = "Adding them to the LAN when they are far away."
That's it. Nothing more.
-
@scottalanmiller said:
@wirestyle22 said:
No I can't. I don't really do anything with mobile devices so I figured I'd ask questions. Sorry I'm not making a ton of sense
VPN = "Adding them to the LAN when they are far away."
That's it. Nothing more.
Yeah but it should make it visible in a way it wasn't before considering we have no MDM system in place. I was wondering how I might use that to my advantage--if its even possible.
-
My unaddressed concerns with the client/server architecture that we keep going round and round on and I've not seen addressed in any way:
- The complexity of combining many data sources when we have no reason to think we have access to the relational information.
- The fact that systems like this often keep relational data that does exist outside of the database and relationships are created and enforced in software, not the database (I'm working with one of those right now, in fact.)
- The fact that ODBC cannot be automated in big systems like this with simple tools because many datasources have to be combined, not just one.
- That the resulting data cannot be provided by a simple "report" as we need to code something to consume many different data sources into one that we massage ourselves and create our own relationships (maybe some tool does this, I don't know of one.)
- The fact that some data sources cannot use ODBC even if relational, but more likely when they are non-relational.
This leaves us with the basic problems: lack of data integrity, lack of resulting product and inaccessibility of data.
-
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
No I can't. I don't really do anything with mobile devices so I figured I'd ask questions. Sorry I'm not making a ton of sense
VPN = "Adding them to the LAN when they are far away."
That's it. Nothing more.
Yeah but it should make it visible in a way it wasn't before considering we have no MDM system in place. I was wondering how I might use that to my advantage--if its even possible.
VPNs do not make things visible that were not visible before. It just makes them visible when they were not on the local network. If you didn't have the functionality when people were in the office before, adding them to the VPN will not create new functionality.
-
@scottalanmiller said:
@johnhooks said:
It wasn't ruled out at all. You said they may be using NoSQL (or no database at all), which is unlikely as these types of data stores are usually too complex for that.
Totally ruled out. Using NoSQL is increasingly common and the use of a single database for huge systems like this is almost never going to happen. That some of the systems use NoSQL or something that cannot use ODBC is an extremely real possibility and increasingly so in the future. That it is unlikely to be the sole datasource is very true, but not relevant.
It may be increasingly common, but not scenarios like this. The data stores actually storing the data are usually relational.
-
@scottalanmiller said:
My unaddressed concerns with the client/server architecture that we keep going round and round on and I've not seen addressed in any way:
- The complexity of combining many data sources when we have no reason to think we have access to the relational information.
- The fact that systems like this often keep relational data that does exist outside of the database and relationships are created and enforced in software, not the database (I'm working with one of those right now, in fact.)
- The fact that ODBC cannot be automated in big systems like this with simple tools because many datasources have to be combined, not just one.
- That the resulting data cannot be provided by a simple "report" as we need to code something to consume many different data sources into one that we massage ourselves and create our own relationships (maybe some tool does this, I don't know of one.)
- The fact that some data sources cannot use ODBC even if relational, but more likely when they are non-relational.
This leaves us with the basic problems: lack of data integrity, lack of resulting product and inaccessibility of data.
An API is not some magic thing that suddenly provides all of this. An API has to be written to provide this information. It is the very rare API that provides every thing that a user could want to query.
Even if the API was capable of providing all of this mythical access to information, the user would be in the same spot as the person writing the ODBC query. They would be needing to parse down the API returned information to what they want to see.
Is it less complex than learning SQL? Probably a decent amount, but it is far from simple.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
It wasn't ruled out at all. You said they may be using NoSQL (or no database at all), which is unlikely as these types of data stores are usually too complex for that.
Totally ruled out. Using NoSQL is increasingly common and the use of a single database for huge systems like this is almost never going to happen. That some of the systems use NoSQL or something that cannot use ODBC is an extremely real possibility and increasingly so in the future. That it is unlikely to be the sole datasource is very true, but not relevant.
It may be increasingly common, but not scenarios like this. The data stores actually storing the data are usually relational.
That in no way disputes what I said.
-
@JaredBusch said:
@scottalanmiller said:
My unaddressed concerns with the client/server architecture that we keep going round and round on and I've not seen addressed in any way:
- The complexity of combining many data sources when we have no reason to think we have access to the relational information.
- The fact that systems like this often keep relational data that does exist outside of the database and relationships are created and enforced in software, not the database (I'm working with one of those right now, in fact.)
- The fact that ODBC cannot be automated in big systems like this with simple tools because many datasources have to be combined, not just one.
- That the resulting data cannot be provided by a simple "report" as we need to code something to consume many different data sources into one that we massage ourselves and create our own relationships (maybe some tool does this, I don't know of one.)
- The fact that some data sources cannot use ODBC even if relational, but more likely when they are non-relational.
This leaves us with the basic problems: lack of data integrity, lack of resulting product and inaccessibility of data.
An API is not some magic thing that suddenly provides all of this. An API has to be written to provide this information. It is the very rare API that provides every thing that a user could want to query.
Even if the API was capable of providing all of this mythical access to information, the user would be in the same spot as the person writing the ODBC query. They would be needing to parse down the API returned information to what they want to see.
Is it less complex than learning SQL? Probably a decent amount, but it is far from simple.
Thank you, you worded this better than I was able to.
Also what software that's used by any number of people at all does the relations in the software vs in the relational database itself. That defeats the whole purpose of the relational database.
So if we are going to assume bad practices here, why not assume bad practices with the API?
-
@scottalanmiller said:
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
It wasn't ruled out at all. You said they may be using NoSQL (or no database at all), which is unlikely as these types of data stores are usually too complex for that.
Totally ruled out. Using NoSQL is increasingly common and the use of a single database for huge systems like this is almost never going to happen. That some of the systems use NoSQL or something that cannot use ODBC is an extremely real possibility and increasingly so in the future. That it is unlikely to be the sole datasource is very true, but not relevant.
It may be increasingly common, but not scenarios like this. The data stores actually storing the data are usually relational.
That in no way disputes what I said.
It does, because I can pull the info out of the relational database and never need to even know NoSQL exists.
-
@JaredBusch said:
@scottalanmiller said:
My unaddressed concerns with the client/server architecture that we keep going round and round on and I've not seen addressed in any way:
- The complexity of combining many data sources when we have no reason to think we have access to the relational information.
- The fact that systems like this often keep relational data that does exist outside of the database and relationships are created and enforced in software, not the database (I'm working with one of those right now, in fact.)
- The fact that ODBC cannot be automated in big systems like this with simple tools because many datasources have to be combined, not just one.
- That the resulting data cannot be provided by a simple "report" as we need to code something to consume many different data sources into one that we massage ourselves and create our own relationships (maybe some tool does this, I don't know of one.)
- The fact that some data sources cannot use ODBC even if relational, but more likely when they are non-relational.
This leaves us with the basic problems: lack of data integrity, lack of resulting product and inaccessibility of data.
An API is not some magic thing that suddenly provides all of this. An API has to be written to provide this information. It is the very rare API that provides every thing that a user could want to query.
Even if the API was capable of providing all of this mythical access to information, the user would be in the same spot as the person writing the ODBC query. They would be needing to parse down the API returned information to what they want to see.
Is it less complex than learning SQL? Probably a decent amount, but it is far from simple.
I'm not saying that it is simple. I'm just saying that a direct client/server connection leaves you without the normally necessary application layer that assembles and protects the data (in terms of integrity.) It's not magic, but neither is ODBC. The idea with a direct ODBC connection is that a computer can look at a bunch of data and just "know" what it represents but it cannot. The problem is that an API is generally needed here, easy or not, because the other option is generally not even reliably possible (or possibly reliable.)
