OnScanResult()

SirRockALot · 02-21-2004

I tried using OnScanResult() even though the official specs say it's not being used. Too bad this was true, it's not being called. I wonder why this is the case ? Having this callback/event with SSID / Signal / WEP etc. would be EXTREMELY useful and I can't imagine it's more than a few minutes of work to expose that information to the script.

Combined with the MS speech to text API this would be so nice to have, as you can currently only output lost / found APs and best signal strength.

please please add this simple callback ;-)

Thorn · 02-21-2004

Quote:

Originally posted by SirRockALot
... and I can't imagine it's more than a few minutes of work to expose that information to the script. ...

Having done a bit of programming, my experience is the "few minute" jobs are those that seem to take the longest. Then of course there are the 10 million other "few minute" requests that people think the Marius should do.

Moved to the appropriate forum.

SirRockALot · 02-21-2004

I also got quite a bit of programming experience, also with the windows scripting host, and I honestly don't think it would be more than a few minutes of work. If the app was open source, I would happily do it myself.

Of course do I understand that this is a free app and that he can spent his time in every way he wants. It's just that NetStumbler is a truely great app and it would become even more useful to me if I could script a bit more.

Thanks for moving it to the correct forum, you're right.

Kazig · 02-21-2004

Quote:

Originally posted by SirRockALot
I tried using OnScanResult() even though the official specs say it's not being used. Too bad this was true, it's not being called. I wonder why this is the case ? Having this callback/event with SSID / Signal / WEP etc. would be EXTREMELY useful and I can't imagine it's more than a few minutes of work to expose that information to the script.

Combined with the MS speech to text API this would be so nice to have, as you can currently only output lost / found APs and best signal strength.

please please add this simple callback ;-)

If I remember what I read in the Docs, there was a concern about older laptops not being able to handle the volume of data. While several of us can afford newer laptops, I still have a couple of 150mHz laptops that barely handle an active GPS on the Com port. It would turn into a support nightmare.

SirRockALot · 02-21-2004

First, if your machine can't handle it you don't need to use scripting. it's an optional feature and disabled by default. Also, anybody can come up with some super crazy script that can slow down any machine. I just don't accept that argument ;-)

If you have a new scan every second, and you find 100 APs, even a slow laptop can handle that. WSH scripting languages like JScript are not fast, but having 100 script calls per second is is acceptable. Also, why not make a callback that gets only called for new APs ? This would already be very useful and it wouldn't do to many script calls for a scan.

In any case, that feature would be optional and not raise the min. system requirements

Kazig · 02-21-2004

Quote:

Originally posted by SirRockALot
I just don't accept that argument ;-)

Whether or not you agree is of no concern of mine. I don't expect it to change anytime soon.

SirRockALot · 02-21-2004

That sucks, reducing a great app's usefulness for no reason :-(

Kazig · 02-21-2004

Quote:

Originally posted by SirRockALot
That sucks, reducing a great app's usefulness for no reason :-(

If you make a big enough donation to the developer you might get what you want.

nikolatesla20 · 02-24-2004

Actually, it is probably more of a technical issue. I can easily see why it could cause problems.

You really want NS to be as fast as possible, in other words, to be able to pick up new AP's as soon as it sees them. Well, if it calls an external routine when it finds an AP then it has to wait for the external routine to finish (return) before it can detect another AP. So you could miss AP's because of this.

On the other hand, you could construct NS to call the external routine "asynchronously" in which case you wouldn't slow down NS. But now you run into another problem, that you could end up calling the same routine twice in a row really fast. So you still need to serialize the calls somehow. The only way to do that would be to buffer the call until it can be processed, which can be a complex undertaking.

That's why such a routine is a little more complicated than one might think.

-niko

SirRockALot · 02-24-2004

good point. I was assuming that the script calls are already being made in a separate thread. Currently I assume the search for APs is performed in a different thread then UI. The task of placing a script call in qeue is probably similar to adding AP data to the list control in the UI thread. The thread communication wouldn't be to difficult since it's one way with probably only one point of data exchange.

But yeah, I see your point ;-) Too bad the developer doesn't feel comfortable with releasing the source so far.

Kazig · 02-24-2004

Quote:

Originally posted by SirRockALot
good point. I was assuming that the script calls are already being made in a separate thread.

Probably one of the first scripts written for this application would involve real-time database access.

OnScanResult()
Parse Data
...
Open Database
Write Database
Close Database
Exit Script

Overlapping as you pick up 30 APs back to back driving near the university, each triggering the event every scan, every second.

Then add in the mapping program to keep track of where you are, and where you stumbled.

Might get real ugly real quick.

SirRockALot · 02-24-2004

Yes, I was thinking of writing a little mapping app and doing a realtime display. Also I wanted to add some more details to my text-to-speech thing. The speech engine actually eats up a lot of CPU and it can get sortof problematic when running on a Crusoe CPU in power save mode.

I think the db app would be perfectly fine, as writing a few rows to a db is pretty cheap ;-)

Kazig · 02-24-2004

Quote:

Originally posted by SirRockALot
I think the db app would be perfectly fine, as writing a few rows to a db is pretty cheap ;-)

Writing the rows takes little effort, but you can't hold a dbase open between calls to the script. 30 Aps @ 1 scan per second thats 1800 db open/closes per minute.

nikolatesla20 · 02-24-2004

As long as you make a big enough buffer, you could do this real time - the mapping would be a "pull". It would pull the data when available. The main program's job when a new AP is found is simply to shove it on a stack and return, so it suffers no speed problems.

-niko

Kazig · 02-24-2004

Quote:

Originally posted by nikolatesla20
As long as you make a big enough buffer, you could do this real time - the mapping would be a "pull". It would pull the data when available. The main program's job when a new AP is found is simply to shove it on a stack and return, so it suffers no speed problems.

-niko

OK, I'll bite. I've worked with script for several years, but have never seen, or heard of anyone using a persistent stack in script. Or were you talking about moving it back to NS itself.

02-21-2004	#1 (permalink)
SirRockALot Registered Member Join Date: Feb 2004 Posts: 6	OnScanResult() I tried using OnScanResult() even though the official specs say it's not being used. Too bad this was true, it's not being called. I wonder why this is the case ? Having this callback/event with SSID / Signal / WEP etc. would be EXTREMELY useful and I can't imagine it's more than a few minutes of work to expose that information to the script. Combined with the MS speech to text API this would be so nice to have, as you can currently only output lost / found APs and best signal strength. please please add this simple callback ;-)

02-24-2004	#9 (permalink)
nikolatesla20 Registered Member Join Date: Feb 2004 Posts: 27	Actually, it is probably more of a technical issue. I can easily see why it could cause problems. You really want NS to be as fast as possible, in other words, to be able to pick up new AP's as soon as it sees them. Well, if it calls an external routine when it finds an AP then it has to wait for the external routine to finish (return) before it can detect another AP. So you could miss AP's because of this. On the other hand, you could construct NS to call the external routine "asynchronously" in which case you wouldn't slow down NS. But now you run into another problem, that you could end up calling the same routine twice in a row really fast. So you still need to serialize the calls somehow. The only way to do that would be to buffer the call until it can be processed, which can be a complex undertaking. That's why such a routine is a little more complicated than one might think. -niko Last edited by nikolatesla20 : 02-24-2004 at 03:07 PM.

02-24-2004	#14 (permalink)
nikolatesla20 Registered Member Join Date: Feb 2004 Posts: 27	As long as you make a big enough buffer, you could do this real time - the mapping would be a "pull". It would pull the data when available. The main program's job when a new AP is found is simply to shove it on a stack and return, so it suffers no speed problems. -niko Last edited by nikolatesla20 : 02-24-2004 at 05:59 PM.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

02-21-2004	#3 (permalink)
SirRockALot Registered Member Join Date: Feb 2004 Posts: 6	I also got quite a bit of programming experience, also with the windows scripting host, and I honestly don't think it would be more than a few minutes of work. If the app was open source, I would happily do it myself. Of course do I understand that this is a free app and that he can spent his time in every way he wants. It's just that NetStumbler is a truely great app and it would become even more useful to me if I could script a bit more. Thanks for moving it to the correct forum, you're right.

02-21-2004	#5 (permalink)
SirRockALot Registered Member Join Date: Feb 2004 Posts: 6	First, if your machine can't handle it you don't need to use scripting. it's an optional feature and disabled by default. Also, anybody can come up with some super crazy script that can slow down any machine. I just don't accept that argument ;-) If you have a new scan every second, and you find 100 APs, even a slow laptop can handle that. WSH scripting languages like JScript are not fast, but having 100 script calls per second is is acceptable. Also, why not make a callback that gets only called for new APs ? This would already be very useful and it wouldn't do to many script calls for a scan. In any case, that feature would be optional and not raise the min. system requirements

02-21-2004	#7 (permalink)
SirRockALot Registered Member Join Date: Feb 2004 Posts: 6	That sucks, reducing a great app's usefulness for no reason :-(

02-24-2004	#10 (permalink)
SirRockALot Registered Member Join Date: Feb 2004 Posts: 6	good point. I was assuming that the script calls are already being made in a separate thread. Currently I assume the search for APs is performed in a different thread then UI. The task of placing a script call in qeue is probably similar to adding AP data to the list control in the UI thread. The thread communication wouldn't be to difficult since it's one way with probably only one point of data exchange. But yeah, I see your point ;-) Too bad the developer doesn't feel comfortable with releasing the source so far.

02-24-2004	#12 (permalink)
SirRockALot Registered Member Join Date: Feb 2004 Posts: 6	Yes, I was thinking of writing a little mapping app and doing a realtime display. Also I wanted to add some more details to my text-to-speech thing. The speech engine actually eats up a lot of CPU and it can get sortof problematic when running on a Crusoe CPU in power save mode. I think the db app would be perfectly fine, as writing a few rows to a db is pretty cheap ;-)