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?

You're talking non-sense.

The user has the possibility to rename.
So, eventually he'll do that. (worst-case scenario / murphy's law). It's his problem indeed if he renames a MyLib file, but this has strictly nothing to do with having a package manager.

Why would you not want to then update the obsolete DB ? I don't see any good reason to not hook the rename function to update the db if there is no technical difficulty in doing so.
It's just one of the advantage of having an ndlessed calc.

Well, maybe there is another way than having a DB, but filenaming conventions will lead to annoyingly long names.
If there are other solutions, we still haven't found them, then.

All right, I've finished the first version of the TI-Planet API.

Documentation is here : http://tiplanet.org/forum/archives_voir.php?id=19600

TL;DR :
- search within the archives with filters
- get info about an archive by its id
- output possible in json, xml, php-serialized-array, php-print_r
- get/post requests supported
- http & https supported


tell me what else would be needed for the software

the current apikey (will change later...) for the appstore is ... the name of the package manager ndless program followed by the number 42.
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)

Quote

the current apikey (will change later...) for the appstore is ... the name of the package manager ndless program followed by the number 42.
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)

Why 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.

Could you change the author to be always an array? It's better to use foreach($authors as $author) than if(is_array($author))..
Also, it should be possible to retrieve the apps for a given platform. How else should the appstore fetch all available apps?

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?

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 ?

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 ...
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.

Quote from: Vogtinator on August 14, 2013, 01:30:20 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.

Quote from: ExtendeD on August 14, 2013, 01:43:29 pm

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.

- 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).