then, as far as I remember, you can simply increase ReceiveBuffer size =)

much rather just use the API as intended so API tools work w/o changing settings on hosts

thanks for all the info on this, much appreciated.

Thanks Chupaka, thats much more clear than the previous statement, I had previously been doing 1:1 but after that statement decided to test it out

I understand that, but part of the "benefits" of this API is the ability to send more than one command before reading yes? From janisk (in other thread about the API I started) "i can easily run several commands at once and receive responses in a known way, without mixing everything u...

Anyone know what the limitation is of write commands before requiring to read?

I been testing and it seems 3 or so commands come back at the most.... curious if there is a spec for that in particular or way of telling for sure?
(maybe its not command count, but returned data that limits it?)

Thanks

if you have too many to handle using a drop down your mock up does your idea no justice... in reality your mockup would look more like [one | two | thr.. | fou.. | fiv.. | six | sev.. | eig.. | nin.. | ten | ele.. | twe.. | thi.. | fou.. | fif.. | six.. | sev.. | eig.. | nin.. | twe.. ] your availab...

Keith is right, look up your carriers email to SMS gateway address and fire off an email to the correct email address for the carrier/phone# you wish to send an SMS. Easiest way to integrate SMS notifications into any application that I've seen done.

and these are non-native handlers: http://wiki.mikrotik.com/wiki/API#Example_client http://wiki.mikrotik.com/wiki/API#Other_example_clients Only because its a non standard format... not exactly the best comparison, especially since being what it is, they are prone to errors due to being exponential...

True, but lacking a native JSON interface on the MT side, you could (once) write an interface between the MT native API and JSON. Then all further tools use that interface. This is true, I almost have something like this working for my software, I'm still working out the best format to keep it as s...

There are JSON handlers in every popular programming language... whether they are native or not depends on the developers of that language...

Sadly that made little sense... No comment on the sockets tangent I know what JSON vs the API data looks like... my argument isnt in appearances, but ease of consumption $data = json_decode($response); vs reading in and manually parsing a customized word pattern... Guess I wont expect any actual con...

what's wrong with current format? it's not human-readable? CLI is human-readable =) and PHP is not the only programming language... 1) its archaic and difficult to work with 2) I never complained about PHP -- simply said I was working with it... the other API clients that have been written look ver...

I have been working with the PHP API scripts for some time now, and I am wondering if there is any chance that the Router->client data might be modernized... The last time I dealt with formats like this was from military ground terminals from the 70's... (maybe I just dont deal with this type of stu...