Well then knowing what you know think of it this way:
/* Begin Rant Here
How much space must you add to the file system for SMB handling, associated libraries, FTP server, web controls, and don't forget the settings which also have to go into NV storage.
Then consider that you know that the engineers usually (I am making an assumption here, though I feel it should stand, feel free to tell me how you do it at work) fill the available space on release code. Compare that to the size of the 1.11 firmware (in the neighborhood of 1,376,256 bytes according to Windows file properties). True the firmware is compressed, but most of that was binaries, which aren't famous for compressing terribly well.
What gets cut first a new feature or an old respected (and advertised) feature?
While we are at it I might mention that the 1.03 release firmware for the DNS-323 is over 7 MB (7,400,091 bytes by File Properties in Win-Zip), and this and a print server is all that device does!
Now lets add as a bare minimum that much space into RAM (so we can execute those binaries and display those controls). In reality much more will be needed for file buffers (both SMB and FTP).
Are we now violating the designed memory footprint and are going to be locked in waits for RAM?
Now we can discuss CPU cycles, both of the new required daemons are expensive on a constant basis and really expensive during a read or write. Is is possible these spikes are going to get us into a lock for CPU even if only periodically. Also fun to consider is that the traffic which causes a spike in the file daemons also corresponds to a spike on the core functionality, I believe this is what Lycan was referring to by taxing the switch CPU. Then consider that all the functions of this device are real time network functions and adding a thousand cycles to every QoS packets processing time as it gets paged out and in repeatedly will defeat the purpose.
Now we can make the business argument (and the one that should hit closest to home for you). How many developer hours does it take to implement these features? We are not dealing with an open and heavily developed platform like Linux here (given this router has no GPL code on D-Link's site), there is a real possibility that these tools do not exist for this OS. When a feature doesn't work or needs improvement, how many development hours will be spent fixing it.
Compare that to the amount of additional income (0$ per unit), it's true a few more unit's might be sold, but how do you forecast that to justify the business expense (especially given that there is already a near saturated market for that feature [this is where the DNS-323 comes into the picture])? How many don't get sold or get returned due to above performance hits, or the wave of bad reviews proclaiming that the device is unusably slow with modern release code.
As a final salvo I might add that D-Link produced routers with storage code thrown in in the past and they never sold very well (I'm pointing at you DI-624S).
I don't know what kind of embedded application you work with, but this should all be familiar to you.
End Rant Here *\
Now that that is out of my system, a feature request is perfectly welcome, stating that you think you know better than the people developing the device as to what is feasible is sophmoronic.
I am not one of these people, however I think the above sums up the first layer arguments against it. I made a significant number of assumptions above and if you want to discuss then then I think this should be fun.
Though I must stress that at no point do either I or you know exactly how much overhead exists in RAM, ROM, or cycles in which to fit these features. For all I know we have plenty of room, I just don't think that it is safe to assume as much and use that assumption to tell the most knowledgeable person here (the moderator Lycan) that his reasoning doesn't work for you.
I might also add that that the thoughts of Lycan, AWDL, and Rara Avis (listed in order of extreme thought) represent a sane viewpoint in my opinion (though Rara might be going a little far).
Author
Topic: DIR-655 no support for USB external drives? (Read 26594 times)