An app store would indeed be nice, but who will do the work of setting it up, maintaining it in the long-term, and sifting through old programs for re-packaging them ?Maybe Linux style repos ? This way devs maintain their stuff themselves and it's pretty easy to set up (you just need an HTTP server and there are plenty of free hosts). ;)
So I would have to download the .pcs package manually, transfer it to my calculator and then install it? :-\At the moment, yes.
Sure, it's easier to install and you won't make any mistakes, but I think a pc-based version (using tilp's libs) would be better, but also harder to code and maintain.A PC-based version is at least on my wishlist ;D
Imagine a public omnimaga and ti-planet repository with almost every app available as "one-click-install".Well, I'll see what I can do. :P
Something like an "Nspire-App-Store", maybe even with automated ndless installation?
Maybe even an "One-Click-Update" which updates all applications installed on the calculator..
Maybe my brain is already dreaming at 2:00 am while I'm still awake typing this post..
Edit: pacspire uses .zip format for the files? What is the installation speed like?I'm at school now and can't give you exact times, but it is not too slow. Try installing the tworld package (~1,8MB uncompressed, ~400KB compressed) and you'll see.
compu: nice :)Sure. And by the way, would it be possible to make the program loader of ndless available to launched programs?
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?Everything zlib-related in os.h is commented out at the moment.
Why not a simple Web UI for submitting and updating apps?An app store would indeed be nice, but who will do the work of setting it up, maintaining it in the long-term, and sifting through old programs for re-packaging them ?Maybe Linux style repos ? This way devs maintain their stuff themselves and it's pretty easy to set up (you just need an HTTP server and there are plenty of free hosts). ;)
Great! If you want to, I could help :DSure, it's easier to install and you won't make any mistakes, but I think a pc-based version (using tilp's libs) would be better, but also harder to code and maintain.A PC-based version is at least on my wishlist ;D
Wow, not too bad for a calculator..Edit: pacspire uses .zip format for the files? What is the installation speed like?I'm at school now and can't give you exact times, but it is not too slow. Try installing the tworld package (~1,8MB uncompressed, ~400KB compressed) and you'll see.
But doesn't nRemote use the mysterious NavNet.jar to interface with the Nspire windows driver?Same here. libti* supports this functionality though as Lionel stated a few posts up. ;)
That would make it completely useless to me, as I'm using Linux.
Will you do the same for other calculator models?Not sure it is a good idea. Take the example of the 83+ (and sorry if I take the examples of my games but those are the ones I think of first).
That's what I was thinking of + a command-line client that downloads packages and sends them to the calc (I guess that would be possible with libti*?).Why not a simple Web UI for submitting and updating apps?An app store would indeed be nice, but who will do the work of setting it up, maintaining it in the long-term, and sifting through old programs for re-packaging them ?Maybe Linux style repos ? This way devs maintain their stuff themselves and it's pretty easy to set up (you just need an HTTP server and there are plenty of free hosts). ;)
Great! If you want to, I could help :DSure, why not :)
But if I click on tworld.pcs.tns again, it says 1.3.0 would be newer than my installed version 1.3.0, but in the log file it states otherwise xD
The installed version of tworld (1.3.0) is newer than the one you are trying to install (1.3.0). Continue?
checking if the package is newer than the installed version... noIt actually says the same, but "installed version" and "package" are interchanged... I should probably change that :D
The [great, in my option] idea of an Nspire App-Store has been in mind of several people for quite some time, yet nothing has been done on that path :PThanks, I will take a look at nRemote, but if it doesn't work on Linux as Vogtinator says, it probably won't be an option.
It could be coupled with some remote control software to automatically extract/isntall/launch whatever. nRemote for example can do that quite easily with its "script" support.
Anyways, great work Compu, that will surely help people installing their programs. I think there should be (if not already present) a way to decide if the installation is done in a specified folder (for in-dev programs that still don't support to be in any folder or don't support their dependencies to be in random folders, or for programs that must be in startup) or in a folder that the user would choose (for programs that can be run from any folder and that the user would like to put in the Game folder for example).Thanks!
Sorry, I may have used too much parentheses or used a not understandable enough English, so there is a part of my request that you didn't see.Anyways, great work Compu, that will surely help people installing their programs. I think there should be (if not already present) a way to decide if the installation is done in a specified folder (for in-dev programs that still don't support to be in any folder or don't support their dependencies to be in random folders, or for programs that must be in startup) or in a folder that the user would choose (for programs that can be run from any folder and that the user would like to put in the Game folder for example).Thanks!
Selecting a folder should be pretty easy to add.
I just tried to read the libticalcs2 HTML-documentation and it seems so outdated, that "nspire" isn't mentioned one singe time.Why not a simple Web UI for submitting and updating apps?That's what I was thinking of + a command-line client that downloads packages and sends them to the calc (I guess that would be possible with libti*?).
I'll try setting up a small application which sends a file to the calculator and maybe even executes it.Great! If you want to, I could help :DSure, why not :)
Even with WINE it doesn't. It needs the navnet device driver installed. TINCL shows a splash screen and then it exits with "Connectivity Library is missing".The [great, in my option] idea of an Nspire App-Store has been in mind of several people for quite some time, yet nothing has been done on that path :PThanks, I will take a look at nRemote, but if it doesn't work on Linux as Vogtinator says, it probably won't be an option.
It could be coupled with some remote control software to automatically extract/isntall/launch whatever. nRemote for example can do that quite easily with its "script" support.
Sorry, I may have used too much parentheses or used a not understandable enough English, so there is a part of my request that you didn't see.forcing an installation folder is easy as well and could be added to the pkginfo.txt, but I'd like to have another solution:
-I was indeed asking for a "folder selection menu" or something.
-But also a way for developers to force the "unpacking folder", so that a program that must be put in "startup" will always be put in startup (doesn't ask the user where to unpack), or so that a program that is still in-dev and that must be ran from the Ndless folder (and nowhere else) will be unpacked in the Ndless folder.
I just tried to read the libticalcs2 HTML-documentation and it seems so outdated, that "nspire" isn't mentioned one singe time.Yup, I only found outdated documentations as well. Maybe, Lionel, if you are reading this... :P
But as tilp runs fine and some files in src begin with nsp_*, I think it's the right library in the right version.
So is tilp the only reliable source for documentation?
And I wonder why there are four libti* librarys. In my opinion it would have made more sense to combine them into one libticalcs..
I'll try setting up a small application which sends a file to the calculator and maybe even executes it.Nice :)
Even with WINE it doesn't. It needs the navnet device driver installed. TINCL shows a splash screen and then it exits with "Connectivity Library is missing".:/
How should the calculator and the App Store play together? Should the store extract the archive and send all the files or should the appstore send the package to the calculator and start pacspire to install it? The latter sounds better in my opinion, but I think it'll get close to impossible, as pacspire can't communicate with the appstore in any ways except screenshots and files (and that only if no ndless app is running!) :banghead:I'd let pacspire do the work. Some posts ago Lionel said libticalcs has support to send keystrokes, maybe that would work somehow? ;D
But doesn't nRemote use the mysterious NavNet.jar to interface with the Nspire windows driver?
That would make it completely useless to me, as I'm using Linux.
But doesn't nRemote use the mysterious NavNet.jar to interface with the Nspire windows driver?Same here. libti* supports this functionality though as Lionel stated a few posts up. ;)
That would make it completely useless to me, as I'm using Linux.
So is tilp the only reliable source for documentation?The documentation of libti* was already incomplete / partially outdated when I became the maintainer, and (with the help of contributors) I have focused more on the code (which needs bugfixes, feature expansion and hardening) than on the documentation (all the more libti* have relatively few users, and documentation of the API has pretty little user-visible effect, eh ?), so yeah, the source code of the libraries and testcases is your best bet. You're coders as well, after all ;)
And I wonder why there are four libti* libraries.Actually, for the combination of TI-Z80, TI-68k and Nspire, four libraries is not enough ;)
In my opinion it would have made more sense to combine them into one libticalcs.It's equally clear that for the narrower purposes of interacting with the sole Nspire series, four libraries are far too much, and you're completely right about a single library making sense:
Even with WINE it doesn't.USB support in Wine is in the "TODO" group, anyway.
Remember the main point here, whatever the choice : it has to be extremely simple for the user (no installation would be great)Well, the "no installation" part is not going to happen, especially on Windows, due to the "everything USB needs a driver, which in turns requires admin privileges for installing" behaviour. On the day the two main FLOSS Web browsers (Firefox and Chrome) start providing an interface to USB peripherals on the host (notwithstanding the severe security problems), maybe...
One of the NavNet JARs (don't remember which one) contains the 3-byte key code definitions. Adriweb, remind us which one ;)I... don't remember off the top of my head, but I've read here and there it can be in commproxy.jar ; seems about right. (then, a class like NspireVirtualKeyStroke )
BTW, libticalcs contained support for Nspire remote control before nRemote was released, though I used a beta version of nRemote in a Windows VM to debug and fix my implementation of the feature through sniffing USB packets.Well, it's not as if it was a competition :P
You don't need the 3-Byte key code definition. You can just send ascii, as shown in my code ;)Yes, but in case you want to actually send nspire-related keystrokes :P
I think the requirement to have tilp installed is as easy for the average windows user as having the TI software.But doesn't nRemote use the mysterious NavNet.jar to interface with the Nspire windows driver?
That would make it completely useless to me, as I'm using Linux.But doesn't nRemote use the mysterious NavNet.jar to interface with the Nspire windows driver?Same here. libti* supports this functionality though as Lionel stated a few posts up. ;)
That would make it completely useless to me, as I'm using Linux.
Yes sure, but at least it will function directly and more quickly (no install time, I mean) for those on windows (and mac) with TINC[L]S installed, with no need of filter driver and such because of that crappy windows roadblock...
For Linux obviously libti* is the choice as it's easy to use there (and, well, is the only one).
Remember the main point here, whatever the choice : it has to be extremely simple for the user (no installation would be great)
And, also, let's not forget that if such App-Store project comes to life, it'll have to be for all .tns of course (there are tons of TI activities that could use this, but also Lua scripts, and duh, the ndless programs (especially those with external resources), so if it ever gets popular (who knows :P), the majority of users will be PC, then Mac, then Linux (and the order of file type will be TI BASIC things, then the Lua stuff, then the ndless stuff...)For a real package manager (like pacspire ;) ) every file is just a file, nothing special (except the metadata, of course).
Oh, that wouldn't be a good idea. I prefer having a single repo. Fetching packages and metadata would get horribly slow and what is with different version (but same version number!) of the same app in two repos?
Also, it'd be good to have such a program linked to the major community repos (ticalc, omni, tiplanet, cemetech...)
Oh, the usual fear of documentation :PQuoteSo is tilp the only reliable source for documentation?The documentation of libti* was already incomplete / partially outdated when I became the maintainer, and (with the help of contributors) I have focused more on the code (which needs bugfixes, feature expansion and hardening) than on the documentation (all the more libti* have relatively few users, and documentation of the API has pretty little user-visible effect, eh ?), so yeah, the source code of the libraries and testcases is your best bet. You're coders as well, after all ;)
That's good, although some things like
Have a look at libticalcs (calc_xx -> calc_nsp -> nsp_cmd -> nsp_vpkt -> nsp_rpkt) and the testcase, libticables (link_xxx -> link_usb) and the testcase, TILP (especially tilp_calcs.c), titools. The testcases and titools are about as bare-bones as you can get.
#define TRYF(x) { int aaa_; if((aaa_ = (x))) return aaa_; }can already be called obfuscation :PIt's c:/Program Files (x86)/TI Education/TI-Nspire Computer Link/lib/commproxy/commproxy.jar /com/ti/et/education/commproxy/NspireVirtualKeyStroke.java
One of the NavNet JARs (don't remember which one) contains the 3-byte key code definitions. Adriweb, remind us which one ;)
Oh, I don't think sending keys is a good solution. What if the user presses a key manually or disconnects the calc?
BTW, libticalcs contained support for Nspire remote control before nRemote was released, though I used a beta version of nRemote in a Windows VM to debug and fix my implementation of the feature through sniffing USB packets.
Why seperate conversion from file types?QuoteAnd I wonder why there are four libti* libraries.Actually, for the combination of TI-Z80, TI-68k and Nspire, four libraries is not enough ;)
There's a clear need for a fifth library on top of the four current ones, so as to consolidate some code currently duplicated, with variations, across clients (TILP, TIEmu, TilEm, titools). I started creating it locally, though it contains pretty little.
The whole libti* framework looks complex and seems to have deep nesting of functions, but after a while maintaining the code base, I realized that for the purposes of presenting a single, mildly abstracted API to clients (instead of at least three sets of APIs with significant overlap, due to TI-Z80/TI-68k/Nspire, DBUS/DUSB/NSP, and some commonalities between TI-Z80 and TI-68k), it's not easy to do simpler. Just follow the call chains I outlined above - there's a use for each file, in the complete framework :)QuoteIn my opinion it would have made more sense to combine them into one libticalcs.It's equally clear that for the narrower purposes of interacting with the sole Nspire series, four libraries are far too much, and you're completely right about a single library making sense:
* libticonv deals with character conversion, which is necessary on TI-Z80 and TI-68k models, but the Nspire uses Unicode (and conversions can be handled more directly by other frameworks);
* libtifiles deals with file types... but the Nspire has very few of them, unlike the TI-Z80 and TI-68k series;
* libticables deals with multiple cables... most of which don't work on modern computers due to lack of the physical interfaces, and the Nspire uses a single cable type;Why seperate libticables from libticalcs? Calcs without cables don't work :P
* libticalcs deals with the raw DBUS, DUSB and NSP protocols and transport protocols built on top of them.
The code base is too huge too be maintainable.. A complete rewrite would take years, though.
On my Github, you'll find a one-off experiment of a few hours, where I fused libticonv, libtifiles, libticables, libticalcs and tilp into a single code base (I probably should have let libti* on the one side and tilp on the other side, but oh well), shaved most code related to TI-Z80 and TI-68k calculators. Doing so slashed the size of the code base by more than half (~78K RLOC -> <35K RLOC). I didn't bother thoroughly purging the code base, there remain some bits directly aimed at TI-Z80 or TI-68k series and some APIs which are not necessary for dealing with the Nspire series.
I didn't merge developments from mainline since I created that one-off experiment. With several months of full-time paid work, it would be possible to make a fresh API, simplified from the current one while keeping the good bits, tailored to Nspire interaction, replacing Glib with C++11/STL, making a whole new Qt UI on top of it (GTK+ is falling out of favor), making a solid up-to-date documentation, etc... but who can afford that kind of luxury, all the more it's for the benefit of relatively few users ? At least, I cannot ;)
What means: It's finished in two years but every second application will crash horribly. At least it's my current wine experience..QuoteEven with WINE it doesn't.USB support in Wine is in the "TODO" group, anyway.
Browsers having USB support? Why not integrate firefox in the linux kernel and booting firefox directly? <_<QuoteRemember the main point here, whatever the choice : it has to be extremely simple for the user (no installation would be great)Well, the "no installation" part is not going to happen, especially on Windows, due to the "everything USB needs a driver, which in turns requires admin privileges for installing" behaviour. On the day the two main FLOSS Web browsers (Firefox and Chrome) start providing an interface to USB peripherals on the host (notwithstanding the severe security problems), maybe...
Vogtinator:The problem is more the other direction.. How do you get feedback from the calc(whether the installation has finished successfully, the ndless version..)?
get_event() will be helpful. (http://hackspire.unsads.com/wiki/index.php/Libndls#Keyboard )
It receives keystrokes AND you can receive files while waiting for an event to happen. Pretty awesome and it should solve many problems :D
Test attached. It waits for an event and prints the event data (through serial). If you send a file while waiting, it will be received successfully. (Press ESC to close)
Oh, I don't think sending keys is a good solution. What if the user presses a key manually or disconnects the calc?Well, we could... disable bus access to the keypad while receiving stuff? ;D
The problem is more the other direction.. How do you get feedback from the calc(whether the installation has finished successfully, the ndless version..)?True. How does nRemote receive data from a calc?
Reading a logfile (after executing pacspire) would -again- be slow as hell.
Yeah, a single repo is less of a maintenance problem.QuoteAlso, it'd be good to have such a program linked to the major community repos (ticalc, omni, tiplanet, cemetech...)Oh, that wouldn't be a good idea. I prefer having a single repo.
That's good, although some things likeI removed a number of uses of that ugly, bug-inducing macro over time, but there remain many of them...Code: [Select]#define TRYF(x) { int aaa_; if((aaa_ = (x))) return aaa_; }can already be called obfuscation :P
Does "ticalcs_calc_execute" still work for nspires? That would be perfect, escpecially if you can pass arguments!For our purposes, ticalcs_calc_execute (calc_xx.c) calls into the ".execute" field of the calc_nsp structure defined in calc_nsp.c, which itself points to a function whose entire source code is
static int execute (CalcHandle* handle, VarEntry *ve, const char *args)
{
return 0;
}So libticalcs doesn't support remote execution for the Nspire (while it does for most other models), but I don't know for sure whether the Nspire's OS itself does (the teacher software probably has features like that).Oh, I don't think sending keys is a good solution.For most models, it's the only solution - only the newest protocols (latter DBUS, DUSB) have a proper remote exec command, and maybe the Nspire doesn't :)
What if the user presses a key manually or disconnects the calc?PEBKAC is not much of our concern ^^
Why separate conversion from file types?For character conversion outside of files directly suitable for the calculator - for instance, in program editors. The author of the unfinished, long-unmaintained, buggy KTIGCC considers two-way translation between calculator charset and computer charset as a major feature of his program, but unsurprisingly, it has seen pretty little usage in the wild...
Why seperate libticables from libticalcs? Calcs without cables don't work :PSending files over the wire, and creating the bytes to be sent over the wire, are two strongly different concerns, even though the latter depends on the former.
The code base is too huge to be maintainable.I don't think so, the TILP code base is far from being unmaintainable. It's in a reasonably usable state, and most of the code evolves pretty little, if at all. TIEmu is an unmaintainable code base, however, due to the fragile integration of outdated versions of a patched GDB, Tk, Insight, all of that mixed in the same event loop and sticked together by a fragile build system.
A complete rewrite would take years, though.A partial rewrite of <35K RLOC (some of the code could be copied with little in the way of changes) doesn't take years full-time, but it's still too lengthy a task for me to take on. There are other, more fun and more productive tasks to work on...
Browsers having USB support? Why not integrate firefox in the linux kernel and booting firefox directly? <_<Well, people do lots of crazy stuff with browsers nowadays ;)
I doubt it. What do you want to execute without ndless?QuoteDoes "ticalcs_calc_execute" still work for nspires? That would be perfect, escpecially if you can pass arguments!For our purposes, ticalcs_calc_execute (calc_xx.c) calls into the ".execute" field of the calc_nsp structure defined in calc_nsp.c, which itself points to a function whose entire source code isCode: [Select]static int execute (CalcHandle* handle, VarEntry *ve, const char *args)So libticalcs doesn't support remote execution for the Nspire (while it does for most other models), but I don't know for sure whether the Nspire's OS itself does (the teacher software probably has features like that).
{
return 0;
}
Or giving up this communication and letting the app store handle everything. A version on-calc would still be needed to install an app on a friend's calculator without any PC near.QuoteOh, I don't think sending keys is a good solution.For most models, it's the only solution - only the newest protocols (latter DBUS, DUSB) have a proper remote exec command, and maybe the Nspire doesn't :)
It is at least a bit. Imagine after the file transfer finished the user presses escape (to play the game) and the appstore displays an error message?QuoteWhat if the user presses a key manually or disconnects the calc?PEBKAC is not much of our concern ^^
Why not both layers in one library?QuoteWhy separate conversion from file types?For character conversion outside of files directly suitable for the calculator - for instance, in program editors. The author of the unfinished, long-unmaintained, buggy KTIGCC considers two-way translation between calculator charset and computer charset as a major feature of his program, but unsurprisingly, it has seen pretty little usage in the wild...QuoteWhy seperate libticables from libticalcs? Calcs without cables don't work :PSending files over the wire, and creating the bytes to be sent over the wire, are two strongly different concerns, even though the latter depends on the former.
Especially this project here ;)QuoteThe code base is too huge to be maintainable.I don't think so, the TILP code base is far from being unmaintainable. It's in a reasonably usable state, and most of the code evolves pretty little, if at all. TIEmu is an unmaintainable code base, however, due to the fragile integration of outdated versions of a patched GDB, Tk, Insight, all of that mixed in the same event loop and sticked together by a fragile build system.
When I made the strip_tilp_nspire experiment, I didn't expect TI to come up with a new crappy, totally non-innovative TI-Z80 model, aimed at milking customers and expanding the lifespan of the TI-Z80 series by years...QuoteA complete rewrite would take years, though.A partial rewrite of <35K RLOC (some of the code could be copied with little in the way of changes) doesn't take years full-time, but it's still too lengthy a task for me to take on. There are other, more fun and more productive tasks to work on...
Tilp itself isn't the problem, in fact, it's the filter driver for windows.... :( The number of people willing to install new software (especially drivers, in fact, with some manual configuration...) for this would be very low...Yes sure, but at least it will function directly and more quickly (no install time, I mean) for those on windows (and mac) with TINC[L]S installed, with no need of filter driver and such because of that crappy windows roadblock...I think the requirement to have tilp installed is as easy for the average windows user as having the TI software.
For Linux obviously libti* is the choice as it's easy to use there (and, well, is the only one).
Remember the main point here, whatever the choice : it has to be extremely simple for the user (no installation would be great)
With the big advantage of not having a 42th abstraction over the real communication.
Yep, good enough :)QuoteAnd, also, let's not forget that if such App-Store project comes to life, it'll have to be for all .tns of course (there are tons of TI activities that could use this, but also Lua scripts, and duh, the ndless programs (especially those with external resources), so if it ever gets popular (who knows :P), the majority of users will be PC, then Mac, then Linux (and the order of file type will be TI BASIC things, then the Lua stuff, then the ndless stuff...)For a real package manager (like pacspire ;) ) every file is just a file, nothing special (except the metadata, of course).
QuoteAlso, it'd be good to have such a program linked to the major community repos (ticalc, omni, tiplanet, cemetech...)Oh, that wouldn't be a good idea. I prefer having a single repo. Fetching packages and metadata would get horribly slow and what is with different version (but same version number!) of the same app in two repos?
Yeah, a single repo is less of a maintenance problem.That's perfectly true.... but what repo is going to be used ?
Yes, but Tilp uses libti*, which means it works if it's installed.Tilp itself isn't the problem, in fact, it's the filter driver for windows.... :( The number of people willing to install new software (especially drivers, in fact, with some manual configuration...) for this would be very low...Yes sure, but at least it will function directly and more quickly (no install time, I mean) for those on windows (and mac) with TINC[L]S installed, with no need of filter driver and such because of that crappy windows roadblock...I think the requirement to have tilp installed is as easy for the average windows user as having the TI software.
For Linux obviously libti* is the choice as it's easy to use there (and, well, is the only one).
Remember the main point here, whatever the choice : it has to be extremely simple for the user (no installation would be great)
With the big advantage of not having a 42th abstraction over the real communication.
The reason why I proposed nRemote is because it works "directly" as long as you have TINC[L]S (and well, it's Java, so at least it's mac+windows directly, too)
Importing them manually or automatic, and maybe displaying a message that new apps shouldn't be uploaded there.QuoteAlso, it'd be good to have such a program linked to the major community repos (ticalc, omni, tiplanet, cemetech...)Oh, that wouldn't be a good idea. I prefer having a single repo. Fetching packages and metadata would get horribly slow and what is with different version (but same version number!) of the same app in two repos?QuoteYeah, a single repo is less of a maintenance problem.That's perfectly true.... but what repo is going to be used ?
ticalc.org and tiplanet.org are the two websites with most nspire-related files (I dont know which has more, honestly, but I know tiplanet has a lot ...)
We (tiplanet) probably wouldn't have a problem making some php layer/web-service ( / API) to get the correct files in a wanted format over our archives system as it is right now, IDK about ticalc.org
MySQL Database with all apps and AUTO_INCREMENTed ID + Subdirectories.QuoteHaving a user-exposed file to edit repos and rules to get files from it (if not "standard" from the software POV, or something, IDK), would be cool.
<XML STUFF>
<repository version="0.1" name="TI-Planet main repo">
<app name="Tile World" version="1.3.0" id="1" cx="true" classic="true">
<screenshot>1/screenshot.png</screenshot>
<description>First app available here</description>
<author>ajorians</author>
<package version="0.1">1/tworld.pcs.tns</package>
</app>
</repository>On http://apps.tiplanet.org/index.php you would get a nice login and registration form (or the forum accounts)Forcing a whole classroom of calculators to open an activity when starting a lesson ?QuoteSo libticalcs doesn't support remote execution for the Nspire (while it does for most other models), but I don't know for sure whether the Nspire's OS itself does (the teacher software probably has features like that).I doubt it. What do you want to execute without ndless?
I can only speculate about it, as the organization of the libraries was made before my time as the maintainer, but at least, having libticables separate from libticalcs makes it possible to depend on libticables without depending on libticalcs, if one wants to implement completely different protocols :)QuoteSending files over the wire, and creating the bytes to be sent over the wire, are two strongly different concerns, even though the latter depends on the former.Why not both layers in one library?
Communication over XML, e.g:JSON is more lightweight.
The reason why I proposed nRemote is because it works "directly" as long as you have TINC[L]S (and well, it's Java, so at least it's mac+windows directly, too). But then, no Linux indeed. To be good, the backend thing about communication should be separate, so that on Mac and Windows, users could use the nRemote layer (well, the java thing, that is, not the whole nRemote obviously), and on Linux, Tilp.It's not desirable for a portable community software to depend on TI's proprietary software. The fact that Ndless 1.0/1.1 do it is not a good reason for doing the same thing ;)
My original idea was to install all packages into a central directory (e.g. /pacspire/) and to create a shortcut to the program in the documents folder (shouldn't be hard if ndless's ploader was exposed to pacspire).Jup, I agree with that. It should be fairly easy to integrate that into ndless or even call the hook manually.
Pacspire itself would get a simple GUI to list and remove packages.Dynamic linking? That's even slower than loading elfs on the nspire. And you'll get many dependency problems and so on..
Adriweb said pacspire should be able to install everything, including TI-BASIC and Lua stuff, but they 1. would have to be in the documents folder and 2. mostly are a single file (aren't they? I use TI-BASIC/Lua rarely), so I'm not sure how pacspire should keep track of that or if it is overkill to use a package manager for this (unless you are packing a bunch of scripts into a single package, or a lua script has dependencies like a luax extension, btw random thought: dynamic linking with ndless would be nice :P)
On the PC side, a small tool to generate packages and sending packages to the calc using nRemote/libti* would be nice.If you want shortcuts in /documents/ you should add something like link_prog=tworld.tns and optionally autostart_prog=tworld.tns
So, what information has to be stored in a package?
Currently, there is a simple file called pkginfo.txt.tns with the following format:
name=Package name
version=Version string
timestamp=UNIX Timestamp (e.g. 1375988987)
and optional:
ext_name=txt
ext_prog=editor
The parser for this file is really crappy at the moment, it could be replaced by a real .ini-parser or something.
The next question is, should all packages be unzipped by default? Or should they be unzipped at runtime into a temporary folder? Or should pacspire pass an unzip-handle to the program so it can unzip its resources directly into RAM?That means modifying the programs and the programs wouldn't have full control over the files anymore (as they're only "virtual"). So I vote for the first option.
There could probably be an option for this in the pkginfo file.I think so! At least I want to be reminded of a new ndless version if my nspire is plugged in. For apps it would be very practical.
Of course a central repository would be nice, but is it feasible and worth the effort?
Of course a central repository would be nice, but is it feasible and worth the effort?lolno
If we have enough apps, a central source to get them would be very useful, how many are there approximately?More than 100 :P (many of them are outdated though)
Well, I think we should start small (installing/removing/listing packages, autostart support, shortcuts, everything in a central folder outside of /documents/ hidden from the user -> no .tns extension needed) and then decice what to do next?This so much, I'd be happy to contribute.
Nice :)Well, I think we should start small (installing/removing/listing packages, autostart support, shortcuts, everything in a central folder outside of /documents/ hidden from the user -> no .tns extension needed) and then decice what to do next?This so much, I'd be happy to contribute.
Sure. And by the way, would it be possible to make the program loader of ndless available to launched programs?
A program associated to .lnk isn't needed?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() (http://hackspire.unsads.com/wiki/index.php/Ndless_features_and_limitations#Builtin_functions) to Ndless/Ndless SDK r877 (http://www.unsads.com/projects/nsptools/downloader/download/category/1). 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.
Will hiding them fix the speed issue? I know that on the TI-84+, when programs are locked and not visible from the EDIT menu, there is a massive lag when moving the cursor from one program to another below 50+ locked programs. Of course, the Nspire is a different calc, but since TI still coded it, who knows? >.< I never ever tried any file management tool for the TI-Nspire.Yes it works. Basically because "hiding" a program on a z80 calc was about hiding it from the users, not displaying them, but they still were in the "list of present programs". But on a Nspire, HideManager doesn't only hide the program from the user, it moves the program to a place that is not checked by the OS when displaying the My Documents" menu. So it is not only hidden, but also not parsed, which makes displaying faster.
Will hiding them fix the speed issue? [...] who knows? >.<Experiments (http://tiplanet.org/forum/viewtopic.php?t=10191) have shown that hiding files solves the big delay encoured when accessing the My Document view, so we know.
Do we want to support calculators without ndless installed (newer models, or if the owner isn't allowed to)?I'm not sure how could we support calculators without Ndless installed, when neither BASIC, nor Lua, can read and write files ?
Can libticables send files to hidden folders?Well, hidden folders are outside of the /documents hierarchy, correct ? libticalcs is not any more able to send files outside of this hierarchy than TINC(L)S is. It might be on OS 1.xx, which contain a directory traversal vulnerability used for dumping the Nspire's OS (there's a better way, not implemented by libticalcs), but not on the OS versions we care about...
Good :)Will hiding them fix the speed issue? [...] who knows? >.<Experiments (http://tiplanet.org/forum/viewtopic.php?t=10191) have shown that hiding files solves the big delay encoured when accessing the My Document view, so we know.
QuoteDo we want to support calculators without ndless installed (newer models, or if the owner isn't allowed to)?I'm not sure how could we support calculators without Ndless installed, when neither BASIC, nor Lua, can read and write files ?
What's more, in general, on principle grounds, we don't need or want to support the views of the manufacturer and school system. Most programs which could be installed through a package managers are games, because it's easier to make games than integrate with the OS.
I'd be great to have the appstore recognize packages installed with pacspire and vice versa.Approchaing some sort of a "syncing" feature, then, at the same time :) With a list.txt.tns within /documents that would be retrieved and parsed to see what's installed, the version, etc.
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...
- if the calc is not ndlessed, warn the user that the files won't be transfered outside of /documents, and that, of course, only Basic + Lua based .tns will work, unless they install Ndless (give a link and/or automate the installation if the user accepts to install it).OK, so you're thinking about moving more functionality on the computer side than I was thinking. That could be an option.
- if ndlessed, then, it will be transfered within /documents temporarily and then handled by the calc program to be moved somewhere else with a directly-user-accessible link created.
There are far more than "a few dozen persons" who can install Ndless...But many school require OS > 3.1. The nspire is not a "gaming" platform, it's a calculator.
OK, so you're thinking about moving more functionality on the computer side than I was thinking. That could be an option.Is libti* able to send and receive files without *.tns? At least "/documents/packspire/packages.txt" or whatever the database will be called should be hidden.
Of course, but not so many if you're combining the conditions : getting aware of the project && getting convinced it is a good idea && resticting (with no other motive than pissing the management off) to ndless files[/b].Quoteyou'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...
Ah, yes, sorry for not being clearer.Quote- if the calc is not ndlessed, warn the user that the files won't be transfered outside of /documents, and that, of course, only Basic + Lua based .tns will work, unless they install Ndless (give a link and/or automate the installation if the user accepts to install it).OK, so you're thinking about moving more functionality on the computer side than I was thinking. That could be an option.
- if ndlessed, then, it will be transfered within /documents temporarily and then handled by the calc program to be moved somewhere else with a directly-user-accessible link created.
We're still very heavily in the brainstorming / planning phase, we'll prioritize features and make a design later :)Sure, yes, options like that could be done later, it's not so important at first.
Is libti* able to send and receive files without *.tns?Nope, not more than TINC(L)S.
Oh, BTW, you're wrong when saying "neither BASIC, nor Lua, can read and write files" : there are (and not just a handful) Lua and Basic projects that come with multiple files that have to be put inside of MyLib, to function, so they are reading/writing to external things, just not very freely.I guess I could have written a mention such as "for our purposes"... but for pretty much everyone, "reading and writing files" means reasonable access to the filesystem, rather than limited, platform-specific functionality. TI's peculiar understanding of "reading and writing files" is not what we need for the purposes of the program we're currently discussing.
Right, but the thing is that we have to support these kinds of documents since it's exactly the purpose of pacspire : easier multi-file projects installation :)I was mostly thinking about reading writing the aforementioned calculator-side list of packages / files / whatever, not for the documents themselves.
But as said, before, whatever the type, lua, basic, or ndless, it should not have to matter to the program (both computer and calc side)I'm pretty sure it will matter, because Ndless programs will have to be installed differently from the basic/lua stuff (outside from /documents/, with shortcuts, file extensions, etc.)
But as said, before, whatever the type, lua, basic, or ndless, it should not have to matter to the program (both computer and calc side)As said by other people earlier, there is no interest in making pacspire support Lua nor Basic program, since they are only one-file-made.
But as said, before, whatever the type, lua, basic, or ndless, it should not have to matter to the program (both computer and calc side)I'm pretty sure it will matter, because Ndless programs will have to be installed differently from the basic/lua stuff (outside from /documents/, with shortcuts, file extensions, etc.)
You don't seem to have read :But as said, before, whatever the type, lua, basic, or ndless, it should not have to matter to the program (both computer and calc side)As said by other people earlier, there is no interest in making pacspire support Lua nor Basic program, since they are only one-file-made.
Oh, BTW, you're wrong when saying "neither BASIC, nor Lua, can read and write files" : there are (and not just a handful) Lua and Basic projects that come with multiple files that have to be put inside of MyLib, to function, so they are reading/writing to external things, just not very freely.nor :
Of course, but not so many if you're combining the conditions : getting aware of the project && getting convinced it is a good idea && resticting (with no other motive than pissing the management off) to ndless files[/b].
I'm just trying to help growing the targeted people ("catchment area" / "zone de chalandise" Tongue)
You don't seem to have read : [...] nor [...]Yeah, I skipped an entire page ... damn me.
But I have to say it's difficult to keep up for new posts in this topic while writing :P
You don't seem to have read : [...] nor [...]Yeah, I skipped an entire page ... damn me.
But I have to say it's difficult to keep up for new posts in this topic while writing :P
Then, yes, for MyLib Basic/Lua programs, there is an interest, but how many are they exept Make3D demo and FormulaPro ?
On another topic, talking about web hosting, what should differ from the existing if there is no PC-side client ?Hmm.. the computer side is to have a unified repo-browsing and transferring experience that also makes the whole package-with-metadata thing easier (not made by hand by the user).
I mean what will be the differences between TI-Planet hosting (https://tiplanet.org/index.php?mod=archives&ac=cat3) and the pretty concept posted earlier (http://ourl.ca/19357/357368) ?
It won't be too much work to get support for such apps in, too.You don't seem to have read : [...] nor [...]Yeah, I skipped an entire page ... damn me.
But I have to say it's difficult to keep up for new posts in this topic while writing :P
Then, yes, for MyLib Basic/Lua programs, there is an interest, but how many are they exept Make3D demo and FormulaPro ?
Some programs of critor, too :P
And some "big" basic (and rarer, Lua, like your Make3d, yes) projects by other community members or even TI sometimes.
And, the two things above are the exact same thing, just with a different layout. We would need a native client, which also handles transferring the files (libticalcs + Qt?).On another topic, talking about web hosting, what should differ from the existing if there is no PC-side client ?Hmm.. the computer side is to have a unified repo-browsing and transferring experience that also makes the whole package-with-metadata thing easier (not made by hand by the user).
I mean what will be the differences between TI-Planet hosting (https://tiplanet.org/index.php?mod=archives&ac=cat3) and the pretty concept posted earlier (http://ourl.ca/19357/357368) ?
Concerning TI-Planet, since we'd already talked about having some API to get archive-info and whatnot (-in JSON, I believe, but that's not much the point), this would be the chance to get it done for a good/well-defined purpose.
QuoteAnd, the two things above are the exact same thing, just with a different layout. We would need a native client, which also handles transferring the files (libticalcs + Qt?).On another topic, talking about web hosting, what should differ from the existing if there is no PC-side client ?Hmm.. the computer side is to have a unified repo-browsing and transferring experience that also makes the whole package-with-metadata thing easier (not made by hand by the user).
I mean what will be the differences between TI-Planet hosting (https://tiplanet.org/index.php?mod=archives&ac=cat3) and the pretty concept posted earlier (http://ourl.ca/19357/357368) ?
Concerning TI-Planet, since we'd already talked about having some API to get archive-info and whatnot (-in JSON, I believe, but that's not much the point), this would be the chance to get it done for a good/well-defined purpose.
Althogh Java is absolute crap to develop a graphical application in, it might be the best option.QuoteAnd, the two things above are the exact same thing, just with a different layout. We would need a native client, which also handles transferring the files (libticalcs + Qt?).On another topic, talking about web hosting, what should differ from the existing if there is no PC-side client ?Hmm.. the computer side is to have a unified repo-browsing and transferring experience that also makes the whole package-with-metadata thing easier (not made by hand by the user).
I mean what will be the differences between TI-Planet hosting (https://tiplanet.org/index.php?mod=archives&ac=cat3) and the pretty concept posted earlier (http://ourl.ca/19357/357368) ?
Concerning TI-Planet, since we'd already talked about having some API to get archive-info and whatnot (-in JSON, I believe, but that's not much the point), this would be the chance to get it done for a good/well-defined purpose.
I'd very much like to insist that to get as many people attracted to this project as possible, something without any external install would be better, and thus it's why I'd be thinking of a Java program which :
- if running on Linux, uses libti*
- if Mac or Windows, detect if TINC[L]S is installed, then use navnet, otherwise fallback on libti* if installed.
On both cases, if no transfer "driver" is detected (unlikely...), well, tell the user to get either one. (But the rest of the program could still work)
QuoteAnd, the two things above are the exact same thing, just with a different layout. We would need a native client, which also handles transferring the files (libticalcs + Qt?).On another topic, talking about web hosting, what should differ from the existing if there is no PC-side client ?Hmm.. the computer side is to have a unified repo-browsing and transferring experience that also makes the whole package-with-metadata thing easier (not made by hand by the user).
I mean what will be the differences between TI-Planet hosting (https://tiplanet.org/index.php?mod=archives&ac=cat3) and the pretty concept posted earlier (http://ourl.ca/19357/357368) ?
Concerning TI-Planet, since we'd already talked about having some API to get archive-info and whatnot (-in JSON, I believe, but that's not much the point), this would be the chance to get it done for a good/well-defined purpose.
I'd very much like to insist that to get as many people attracted to this project as possible, something without any external install would be better, and thus it's why I'd be thinking of a Java program which :
- if running on Linux, uses libti*
- if Mac or Windows, detect if TINC[L]S is installed, then use navnet, otherwise fallback on libti* if installed.
On both cases, if no transfer "driver" is detected (unlikely...), well, tell the user to get either one. (But the rest of the program could still work)
Althogh Java is absolute crap to develop a graphical application in, it might be the best option.Yeah, I had Java that in mind because it's at the same time directly cross-platform (no need for external QT and such) and could be linked to both libti* (JNI I guess, loading .dlls or .so or .dylib) and navnet (itself is using JNI but that's the deep navnet part which we won't use, only the high-level stuff are necessary. You can pretty much see what here (https://github.com/adriweb/nRemote/blob/master/src/Remote.java#L169).)
Using JNI to interface Qt with NavNet might be too complex.
*Cough* Just thought I would mention that TILP would not be usable for me (and I'm sure) other windows users. I have never successfully gotten it to run properly on this PC (running windows 7). In fact, the last time I tried to install it (a few months ago) it rendered both TI connect and itself unusable. This was following the instructions to a T. :/Same here (the filter driver thing is what blocked me, all the rest was fine) :/ And of course, it went flawlessly on Ubuntu... Ah, Micro$oft....
I believe this is way more true for z80 platforms than Nspires (and 68k at a lesser extent, though). That's probably because students would get a z80 "by default" whereas a 68k or an Nspire would actually be a choice.QuoteAnd, the two things above are the exact same thing, just with a different layout. We would need a native client, which also handles transferring the files (libticalcs + Qt?).
I'd very much like to insist that to get as many people attracted to this project as possible, something without any external install would be better, and thus it's why I'd be thinking of a Java program which :
- if running on Linux, uses libti*
- if Mac or Windows, detect if TINC[L]S is installed, then use navnet, otherwise fallback on libti* if installed.
On both cases, if no transfer "driver" is detected (unlikely...), well, tell the user to get either one. (But the rest of the program could still work)
You really think that would make people want to use it? Most people pretty much never hook up their calculator to their computer, it's hacky, requires to download tools and has minimal benefits (compared to the work required to implement it nicely). [rant]Plus, who uses a joke like Java anyway?[/rant]
I used to send my buddies games just by cable during classes (oh boy the hours spent during mathematics class playing Pokemon), and that's up to where the majority of people bother to go just to put some stuff on a calculator (and with the package manager at the very most two files would be required to be sent, one if it was integrated into ndless)
If some program relies on specific files and the program binary being in a specific location in /documents, is it possible to disable linking?This shouldn't be necessary, because every Ndless program can easily be adapted to use relative paths (with enable_relative_paths()).
Is is possible to associate a file extension to a hidden program?Yup, as ndless's ploader scans the whole filesystem (except /phoenix) for executables AFAIK.
Could you add an option "savefile=" or something similiar where you can list a file as savefile in the package metadata?Sure, but maybe something like savefolder would be better? :P
On uninstallation, the user will (if the program has savefiles and they exist) be prompted whether they should be removed.
It's hard to remove files in /pacspire..
Would it be possible to hook the deletion of the lnk file (if any) to trigger pacspire so that it can properly uninstall everything, as you say ?Possible: Yes, but probably not for me. Maybe someone who is better at reverse engineering could do it ;)
Possible: Yes, but probably not for me. Maybe someone who is better at reverse engineering could do it ;)On TI-Nspire CX CAS, somewhere between 0x102167A8 and 0x102167F8 you have in [R4] (char **) a pointer to the char sequence containing the name of the currently confirmed deleted file.
I'll make a GUI where it will be possible to remove packages.
Isn't it easier to simply hook the remove() function?remove() is not even called because TI.
(Not the function itself, the location it's pointing to)
Quoteyou'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...
Quoteyou'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.
Of course, but not so many if you're combining the conditions : getting aware of the project && getting convinced it is a good idea && resticting (with no other motive than pissing the management off) to ndless files.
I'm just trying to help growing the targeted people ("catchment area" / "zone de chalandise" :P)
Lionel, you said libti* couldn't handle files in nested directorys, but that is simply wrong, because it works just fine :PThe test program enables doing more stuff, but dirlist of a hierarchy containing nested directories does not work as it should (although an old commit at least prevents it from crashing upon such directory hierarchives, which it used to do) ;)
The test program enables doing more stuff, but dirlist of a hierarchy containing nested directories does not work as it should (although an old commit at least prevents it from crashing upon such directory hierarchives, which it used to do)Umm, it does work? File size and type are correct as well.
TRYF(cmd_s_dir_enum_init(handle, "ndless/games"));
TRYF(cmd_r_dir_enum_init(handle));I overwrote folder_name with "ndless/games" in the library and tilp shows the files just fine :P
assumptions that there's a single / in a valid calculator-side pathby not using a slash in front of the path :P
Wouldn't have it made sense to split the nspire support into an entirely different lib?In 2007, Romain Liévin definitely thought about making a new, fresh library, instead of adding support for the Nspire to libti*.
It doesn't share ANY code (except unneeded, like FileContent, which is for file group support and VirtualPacket)While some of them are definitely unnecessary for the Nspire, don't be too quick to remove all layers of data structures and abstractions. Cable send/receive (libticables) <- raw packet (splitting/reassembling what goes over the wire, nsp_rpkt) <- virtual packet and session handling (nsp_vpkt) <- commands (nsp_cmd) <- calc functions (calc_nsp) <- high-level operations combining multiple functions (e.g. tilp_calcs.c) does make perfect sense, even in the context of a single calculator and protocol series.
and it is very unlikely to be used by an application which supports both the nspire and the other TI calcs.TILP is actually the main use case, the one the libs have always been primarily designed for ;)
At least, you have motivated me for working on the libti*/tilp code base, which I hadn't done for a little whileYay, I did it! But I don't want to be only complaining, I'll presumably look at C++, as it's easier for me to understand the code by rewriting/copying and finding out why it doesn't work anymore ;) But I don't want to promise anything, I'll have some work to do, so it might take a while.
But I don't want to be only complaining, I'll presumably look at C++, as it's easier for me to understand the code by rewriting/copying and finding out why it doesn't work anymore ;) But I don't want to promise anything, I'll have some work to do, so it might take a while.During the next few days, I'll try to finish bringing the strip_tilp_nspire code base towards the code in TILP II 1.17 + associated libraries, as well as making strip_tilp_nspire somewhat less of a one-off hack.
I definitely think we need some way to install something on not jailbroken calcs.Functionality would be severely limited...
QuoteI definitely think we need some way to install something on not jailbroken calcs.Functionality would be severely limited...
And probably a database file for installed programs (updates, uninstall, etc).QuoteI definitely think we need some way to install something on not jailbroken calcs.Functionality would be severely limited...
Well, for non-jailbroken calcs, "installing" would mean to just transfer one or more files into a specific directory, most of the time it'd be /documents (and sometimes /mylib), and.. that's all, since there is no more handling on the calc side.
Looks pretty simple ? (Both with libti* and navnet)
Oh yes, forgot that.And probably a database file for installed programs (updates, uninstall, etc).QuoteI definitely think we need some way to install something on not jailbroken calcs.Functionality would be severely limited...
Well, for non-jailbroken calcs, "installing" would mean to just transfer one or more files into a specific directory, most of the time it'd be /documents (and sometimes /mylib), and.. that's all, since there is no more handling on the calc side.
Looks pretty simple ? (Both with libti* and navnet)
Well, sure, but you can't prevent the user from renaming his files, so, the hooking solution on the rename/move function to update the DB seems to be the best compromise?No, if the user renames the files in MyLib its his problem. Same for a user that roots himself and change the files.
Why would you not want to then update the obsolete DB ?As ExtendeD said, I don't see any reason to maintain a database.
Well, maybe there is another way than having a DB, but filenaming conventions will lead to annoyingly long names.I still don't understand why you need to link the manager to the files. Only the reverse is needed, and, deleting the "link" file, with a hook, will uninstall the installed/hidden files. There is no use to make a reverse link and thus, no need to have a database/naming conventions.
If there are other solutions, we still haven't found them, then.
the current apikey (will change later...) for the appstore is ... the name of the package manager ndless program followed by the number 42.Why not HTTP auth?
Right now it's for debugging/coding purposes I guess, but for production, we'll get a new, "secret" api key (and this current one disabled)
I'll look into that. How is it different/better ?Quotethe current apikey (will change later...) for the appstore is ... the name of the package manager ndless program followed by the number 42.Why not HTTP auth?
Right now it's for debugging/coding purposes I guess, but for production, we'll get a new, "secret" api key (and this current one disabled)
Could you change the author to be always an array? It's better to use foreach($authors as $author) than if(is_array($author))..Why not. Then, same for the categories.
Also, it should be possible to retrieve the apps for a given platform. How else should the appstore fetch all available apps?
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....
Nice start adriweb.Thanks :)
What is the API key for?Basically to avoid misuse/abuse of the API by flooding our server from easily doable (big) requests ... :(
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.
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....We have some RPC going over a DSL 6000 connection (upload 300 kb/s) and the entire student-database(1800 students: class, name, groups, username, email, uid, birthdate..) can be fetched in under 2 seconds. Maybe gzencode (api.php?gz=1, 0 is default)?
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 ?
No probs: http://api:[email protected]/api.php?gz=0QuoteWhy not HTTP auth?I'll look into that. How is it different/better ?
But the good side of that is having the possiblity of getting results through an ajax call in JS, for example, while I'm not sure if it's possible with the http auth.
If I do get it to work, I'll try to support the 3 ways.
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).For now, it doesn't matter how it's called. Some fields are missing a well-formed value (like nspire-os: major.minor) and some major features are missing (screenshot). Maybe even an installation count? Increment on installation and decrement on uninstallation?
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 ?
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.
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.
- the key would only be for the app store software, so just one key, not for its users.
- 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 (?)
Well, running a strings command on the executable would reveal it, probably (depending on how it's hardcoded, though), but 0.01% of the people would try that - and I'm not sure to see why they would do it if they can get their own by "asking".... It's certainly not the best protection but at least it's not nothing, and would stop 90% of novice "hackers"-wannabe. But anyway, without a secure connection, a wireshark sniffing could reveal the data sent... like any program using an api with a key, when not over an encrypted connection- 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.
Well, we'll have to see after some usages what the most often requested things are, and plan accordingly ?Quote- 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).
(mods: feel free to merge if judging as double post, meh)Delete that useless header( stuff. It will only confuse file_get_contents on the other side, me, and my browser, which wants to download a file api-response-something.gz Just output it directly. BTW: gzencode is PHP > 4.0.4, but gzdecode is PHP > 5.4 -.-
I have integrated the &gz=1 (default 0) flag, but I don't really know how to test - at least it gives me no error, either on the client side not the server side :
https://github.com/TI-Planet/API/commit/6dc9c20b761753d08104a9a14173fbbae9e22eaa
I'll be looking at http auth (but there may be some underlying issues with apache/lighttpd that I don't really control / know aboutJust a .htaccess with auth user file and requre valid-user. In the PHP file you can get the user with $_SERVER[PHP_AUTH_USER].
Lionel ?)
(mods: feel free to merge if judging as double post, meh)Delete that useless header( stuff. It will only confuse file_get_contents on the other side, me, and my browser, which wants to download a file api-response-something.gz Just output it directly. BTW: gzencode is PHP > 4.0.4, but gzdecode is PHP > 5.4 -.-
I have integrated the &gz=1 (default 0) flag, but I don't really know how to test - at least it gives me no error, either on the client side not the server side :
https://github.com/TI-Planet/API/commit/6dc9c20b761753d08104a9a14173fbbae9e22eaaQuoteI'll be looking at http auth (but there may be some underlying issues with apache/lighttpd that I don't really control / know aboutJust a .htaccess with auth user file and requre valid-user. In the PHP file you can get the user with $_SERVER[PHP_AUTH_USER].
Lionel ?)
Or make the authentication optional, then serching should only be allowed if the user is authenticated.
Ok, for the header; do I just leave one for the charset or something ?For our RPC the output is simply the following:
And... what about encode/decode, do I need to do something else?
echo gzencode(json_encode($result));Our RPC client uses: $remote = @file_get_contents("http://" . self::$username . ":" . self::$password . "@" . self::$host . "(...)", false, $context);
if($remote === FALSE) (...)
$result = json_decode(gzdecode($remote), true);
And for the .htaccess that's exactly the problem, we don't use them our tiplanet as they don't work (don't ask me why) - last time we tried to understand, we couldn't see...Grep the whole apache config directory for "AllowOverride", most likely that's your issue.
btw, for us lighttpd is for http and apache for https.May I ask why?
Historical reasons :)Quotebtw, for us lighttpd is for http and apache for https.May I ask why?
Yes, it's too old.
No, 877. By request of compu a new feature got added which pacspire uses.the 848 is the newest as I can see
http://www.unsads.com/projects/nsptools/downloader/download/release/1 (http://www.unsads.com/projects/nsptools/downloader/download/release/1)
The last one says 877.
But the last one is 877.:O I was thinking that i was writting/seeing 884 -.-
877 > 848!
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.How did you find it out? I mean, the OS is big and the USB protocol and such things are quite complicated in software.
(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).Oh, the API for TI-8* and nspires is the exact same, so I fear it's not possible without more functions exposed..
I'm not sure if NavNet requires the computer to initiate the service calls (all the standard services are computer to calc...).TINC(L)S, and therefore libticalcs, does it, so I'd say "probably" :)
(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).It's alright to use, in the beginning, an API that you already know because you already used it in the fairly distant past for Ndless.
Oh, the API for TI-8* and nspires is the exact same, so I fear it's not possible without more functions exposed..Wrong. Remember from above, all implemented Nspire functions are exposed by libticalcs nowadays ;)
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.
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 ?
Or do you have other usecases in mind ? (I guess you opened a door for imagination ^^)
Good adriweb :)
And a subset of the NavNet API is now available in Ndless and the Ndless SDK r893 (http://www.unsads.com/projects/nsptools/downloader)!
Documentation (http://hackspire.unsads.com/wiki/index.php/Syscalls#NavNet) is available on hackspire, and samples in Ndless and Ndless SDK.