This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - ExtendeD
Pages: 1 2 [3] 4 5 ... 55
31
« on: August 18, 2013, 03:40:22 am »
How did you find it out? I mean, the OS is big and the USB protocol and such things are quite complicated in software.
Searching for function addresses and finding out which parameter is what surely took long. I have been working with the Java bindings of NavNet for Ndless 1.1 and documenting the protocol a few years ago so I know the main concepts quite well. And logging is extensively available both on the computer and calculator side (NavNet is crossed-compiled). I am giving up researches on the low level USB device API as it appears to be a proprietary Jungo API. Finding the FreeBSD host USBDI API was easier with the FreeBSD source code available. Although that would mean for ndless-calcs only (at least for non-standard stuff I suppose?), the main purposes would be to enhance the features by sending commands to the nspire to, like, automatically move files, for example, once transferred, right ? Yes, maybe its use should be limited to special operations indeed. Or do you have other usecases in mind ? (I guess you opened a door for imagination ^^) I'm a also working on this to provide an API for calc to calc transfers for Ndless programs.
32
« on: August 17, 2013, 08:13:46 pm »
As I'm working on USB calc-to-calc connectivity with Ndless, I'm actually hooking into NavNet, which is the TI-Nspire specific protocol and TI driver for standard OS services (dir listing, screenshots, file transfers, ...). The new syscalls can be used to call services and expose new ones. This may be useful for the package manager if the calculator side wants to communicate specifically with the computer side. http://www.mirari.fr/UcCi (computer side on the left, calculator side on the right, this is a simple echo service). Writing both the client and host programs requires less than 50 lines of code (Interestingly the host side can be ported to the TI-Nspire with few changes for calc to calc transfers, although this might not make sense for a package manager). I'm not sure if NavNet requires the computer to initiate the service calls (all the standard services are computer to calc...). (Lionel, I'm at the moment loading navnet.dll, but switching to libticalcs when running on Linux shouldn't be too difficult I suppose as long as we can match the 2 APIs).
33
« on: August 15, 2013, 03:31:42 am »
- the key would only be for the app store software, so just one key, not for its users.
Then it's a public key, it can't protect you from anything. - I'm not sure a cache would be such a great ID as the request can vary quite enormously, and the cache would get quite huge (?)
It would make sense for requests heavy for the database, search as full-text search (these one are actually not so random) or app listing (a few hundred kb, not so big but I/O intensive for a database).
34
« on: August 14, 2013, 01:55:15 pm »
Also, it should be possible to retrieve the apps for a given platform. How else should the appstore fetch all available apps?
Yeah, for the App Store, I guess I'll have to support that, but this would have to be some kind of "unique" request (like, no more than once every x hours), since it's going to be huge....
I thought of having that supported with some "pages" system. Like, request from 0 to 1000, then 1001 to 2000, etc.
(For now, the max amount of results is 500, and I haven't implemented this "page" system nor the cooldown)
What do you think : page or cooldowned big request ?
Debian uses the compressed Packages.gz for this for instance. Or if you just fear for you database performance, make use of cache. Basically to avoid misuse/abuse of the API by flooding our server from easily doable (big) requests ... 
So, the simpler it is for the third-party user (app store developers etc.), the better it is.
Here, it's just another variable to pass, vogt suggested the HTTP auth, I'll take a look. But how would the key be allocated? Would it be generated for each user? Again making use of a cache or regularly generating static content makes this API key useless. Also don't we want any calc archive site be able to become repository? (i.e. have a TI-Nspire repository API instead of a TI-Planet API).
Well, I suggested that the App Store could read several calc sites indeed, but the reply was that it would be quite difficult to handle multiple versions/duplicates, and such problems.
Ideally... with proper filtering, it could be great to have multiple sources...
But anyway, I can't make any APIs for websites I don't have the DB control ^^
I can also release the API source code, if that helps, only the queries will have to change, the rest is pretty generic.
I mean letting other sites implement the API (as Linux repositories or Eclipse update sites do). The API can be versionned, and a well-defined API doesn't depend on the underlying database structure.
35
« on: August 14, 2013, 01:43:29 pm »
Nice start adriweb.
What is the API key for?
Also don't we want any calc archive site be able to become repository? (i.e. have a TI-Nspire repository API instead of a TI-Planet API).
36
« on: August 13, 2013, 07:39:25 am »
Unsync between the database and the listed could be avoided by not using a database. A well-defined file naming would do I suppose, computer side software can easily discover what's on the calculator with directory listing.
37
« on: August 13, 2013, 07:35:29 am »
Nice update critor 
38
« on: August 13, 2013, 07:32:53 am »
Unfortunately not, for several reasons (hosting costs, possible competitor of OS 3.5 for Android, too many ongoing projects, ...).
39
« on: August 10, 2013, 05:54:52 pm »
you're simply restraining the target of the whole project to a few dozens people... There are far more than "a few dozen persons" who can install Ndless...
As a side note, to get a rough idea of how may new users try Ndless: there are about 1400 visits of the Ndless user guide each month.
40
« on: August 09, 2013, 08:09:46 pm »
Yes, of course this is required
41
« on: August 09, 2013, 07:53:14 pm »
Nice to see that this app store idea is supported, this will help promoting community programs. I have actually been thinking of building one with the Chrome Web Store look and feel (there's strangely no open source clone of it at the moment that could be forked). Sure. And by the way, would it be possible to make the program loader of ndless available to launched programs?
I have just added nl_exec() to Ndless/Ndless SDK r877. I haven't been able to test it extensively yet, tell me if everything works for you. Implementing shortcuts should be straightforward, storing the target path in a plain text file with a .lnk extension should do.
42
« on: August 09, 2013, 03:23:21 am »
compu: nice Would being able to temporary unpack/run/remove temporary files be an interesting option, to avoid cluttering the OS file manager at the expense of launch time? Also how does pacspire conflicts with Ndless's zlib definitions? Vogtinator: an app store would indeed be a nice way to promote TI-Nspire programs which unfortunately often sink into Omnimaga's topic archives after a few months.
43
« on: August 04, 2013, 02:49:11 am »
The SDK should be backward compatible. Which version did you have to use?
45
« on: July 29, 2013, 03:34:10 pm »
Hmm, I looked in the nspire_emu source code and it has a bool value break_on_warn, which is set to true if you have a /W. But break_on_warn is not set to false in the first place! So I guess it could have true or false, randomly.
Global variables should default to 0 (false in this case).
Pages: 1 2 [3] 4 5 ... 55
|
Show Posts