Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Mdram
Caldari Crimson Rain Corp
|
Posted - 2008.02.08 14:45:00 -
[1]
with all the wonderful programs out there for eve that use api information, it might be a good idea if the various developers came up with a standard location to store the xml files.
that way if you use more then 1 application there is less load on the servers, all are up to date, ect
a win win situation for everyone. When in doubt, reload and fire another clip. |
Vessper
The Graduates Brutally Clever Empire
|
Posted - 2008.02.08 17:49:00 -
[2]
I think this is a good idea, but not only for reducing the load on the CCP servers.
If you consider some of the APIs that, after a single call, will return that you can't download for a period of time, then if you do use multiple applications, you can see how a common store could benefit all of them (or at least the ones who can't download the XML due to cache restrictions).
I would suggest that a common location would be in the users application folder, so something like c:\documents and setting\user\application data\EveAPI on XP. A file naming convention would also need to be used to replace the form parameters that are usually passed to the CCP servers when fetching XML. At least then every app would know what to look for and if it's not there, then they can do the usual method of going direct to the Eve API.
--------------
EveHQ Character App | Item Database |
Goncyn
Nomadic Wayfarer Syndicate Te-Ka
|
Posted - 2008.02.08 18:44:00 -
[3]
I was thinking about this a little bit, too, while developing EVE Asset Manager. The problem you of course would run into is that every developer thinks his way is the best way. Me included. For example, I was aware that there were a couple of existing .NET libraries mentioned on the eve-dev wiki, but I decided to write my own instead because they both included object model mappings of the XML data, which I was not interested in.
It's possible we could come to a consensus, if we all got together and discussed it somewhere. But there's not necessarily enough motivation to make it happen.
|
Abbadon
Caldari Pukin' Dogs D0GMA
|
Posted - 2008.02.08 19:00:00 -
[4]
Such a tool already exists and was developed by a member of Goonswarm iirc.
The app is written in PHP and runs on a XAMP server and the post is "somewhere" in this forum section. I will have a search and post a linky when I find it.
How it works:
You make a normal api call from your app, but instead of using eve-online/char/blah.xml.aspx you use myhost/cache.php/char.blah.xml.aspx
the cache app then checks its own mysql table to see if requested xml is current (compares caches timers) - if current, data is handed to app from myhost - if cache timer has expired, myhost makes an api request to eve-online and stores whole xml in myhost table.
I use this with 4 diff api apps an 3 diff PCs and works flawlessly. It also helps a great deal when developing new apps as it means you can grab the xml file as many times as needed.
I hope i explained that well enough - will update later when i find it. .
|
Mdram
Caldari Crimson Rain Corp
|
Posted - 2008.02.08 19:52:00 -
[5]
i was thinking more along the lines of storing your api data on your computer, not at a third party location.
for example if you run eft and evemon, they both need the skill api, but both cannot be up to date at the same time due to the storage location. having a common directory would help with this. whatever program you run, checks for the api in that location, if its not there or out of date, then it downloads it. simple to do. just gotta get everyone on the same page.
probably the easiest way would be if ccp integrated api downloads into the game configuration, basically asking you which ones you wanted to have available, then storing them on your hd, in a location of thier choosing. then have the various application get them from there When in doubt, reload and fire another clip. |
Salvis Tallan
Gallente The Shadow Order SMASH Alliance
|
Posted - 2008.02.08 20:06:00 -
[6]
could always use the Eve-Online folder in your my-documents ------
|
Goncyn
Nomadic Wayfarer Syndicate
|
Posted - 2008.02.08 20:17:00 -
[7]
Originally by: Salvis Tallan could always use the Eve-Online folder in your my-documents
This is bad programming practice, for a couple of reasons. First, it annoys the user, who might not know what the files are and just delete them. Second, this folder might not even exist. I actually use a batch file to launch EVE that sets my profile folder to a subdirectory of D:\EVEData, so I don't get that junk in My Documents. Or the user might not even have EVE installed on the computer they use an API client program on.
The "Application Data" folder in the user's profile is the correct place to store, well, application data.
|
Mdram
Caldari Crimson Rain Corp
|
Posted - 2008.02.08 21:07:00 -
[8]
true, but when multiple program use the same data that can only be received periodically it throws a wrench in th works When in doubt, reload and fire another clip. |
Abbadon
Caldari Pukin' Dogs D0GMA
|
Posted - 2008.02.08 21:16:00 -
[9]
I understand wanting to have the current xml data in a local folder, but that causes problems if you run multiple PC or access from multiple locations.
That is the reason i use the PHP cache app noted in my previous post. I in fact run two copies of this cache app, 1 copy runs on the same server as the corp website/forums killboard, the other copy runs under LAMP on a local PC (this PC also runs a 2nd Eve acct and is of a very low spec).
My xml apps poll the local cache server which in turn polls the Corp Cache server (if that is unavailable it will go straight to EveO)
Using this method i can ALWAYS access my xml from any PC in any location .
|
Goncyn
Nomadic Wayfarer Syndicate
|
Posted - 2008.02.08 21:25:00 -
[10]
Edited by: Goncyn on 08/02/2008 21:26:22 That's a clever setup, Abbadon. But it's not practical for most people. Not everyone has a spare machine to run a LAMP stack on, or the expertise to administer one.
Setting up a central server that performs this service for everyone would solve that problem, but it requires an additional level of trust from the user. Many are already uneasy about providing their API keys to programs that run on their local computers. How many would balk at allowing a third party to store their API data? I would.
There might be ways to set up secure, encrypted storage, but it's difficult to convince non-technical users that it actually is safe, when they don't understand the technology (encryption keys, etc).
|
|
Abbadon
Caldari Pukin' Dogs D0GMA
|
Posted - 2008.02.08 22:58:00 -
[11]
Maybe this is a project for Chribba and his Eve talents. Im sure people would trust a cache placed on his servers.
How do we get his attention tho, maybe saying his name three times?
Chribba Chribba Chribba
.
|
Vessper
The Graduates Brutally Clever Empire
|
Posted - 2008.02.08 23:10:00 -
[12]
I have been toying with the idea of creating a "local" webserver for caching XML files as part of my EveHQ application, and it would work very similar to how Abbadon mentioned in his first point above. Instead of various applications querying the api.eve-online server it would query this webserver. If the data is not there or the cache has expired, then it will head off to Eve-O before returning whatever XML was requested.
This webserver would actually take the form of a windows application so there would be little, if anything to configure for non-technical users (most likely just a port number and an on/off switch). This would work fine on a local network and if the user wanted to open up the port on a router, it could be used outside that also.
The common store on the PC can still be used for multiple applications on that same PC, but where a remote PC requires them, these can be delivered via HTTP from the common store cache.
Well, that's how I see it working anyway
--------------
EveHQ Character App | Item Database |
|
Chribba
Otherworld Enterprises Otherworld Empire
|
Posted - 2008.02.09 08:01:00 -
[13]
I've been having some ideas for the API lately, sort of an API proxy if you want to call it that.
Basicly what sprung into mind was with all these tools out there and people not wanting to give out their full api keys + the fact that there is only one key, as you might want to give keys to A and B, but then disable B, doing so would need you to generate a new key which would disable A until you update it.
So I thought of doing some sort of site that enables you to generate multiple keys and filter content that you might want A to have but not B. Basicly giving you much more control over what gets sent to which requestee.
A cached xml would also be nice with those who use multiple programs/sites that cannot request the same info. I will def do some more thinking of this and see what could be done. Ofc, this would pretty much have the need for developers to recode their stuff to use any of my caches if so.
imo the need for multiple keys and more control of what info gets sent where is needed, question is if ccp is actually going to do that or if we need to rely on a 3rd party?
Secure 3rd party service ■ Do you Veldspar? |
|
Leyawiin
|
Posted - 2008.02.09 21:21:00 -
[14]
As a user I wouldn't trust some online service using my API keys to retrieve data and providing it to various programs. A lot of information gets to be available for 'some' guy running the service. We don't want that!
The best solution would be local storage in such a way that programs like EVEMon and EFT communicate with a local service providing them with the information they require in such a way that API keys remain invisible to those programs. All benefits mentioned earlier will be there: more applications using the same data means less load, more up-to-date data for all programs etc.
Biggest problem is interoperability between the API Service and the programs written in various languages.
Interesting topic, I'll keep thinking about this ;). |
Amida Ta
German Mining and Manufacture Corp.
|
Posted - 2008.02.10 09:12:00 -
[15]
Originally by: Mdram with all the wonderful programs out there for eve that use api information, it might be a good idea if the various developers came up with a standard location to store the xml files.
that way if you use more then 1 application there is less load on the servers, all are up to date, ect
a win win situation for everyone.
The idea itself is good. However there is one more problem: Not every library saves the unmodified retrieved files as cache. My library EveAI.Live e.g. adds some additional XML tags when saving the cache files. That may not be a problem for other applications as long as they are handling the XML correctly. But it would be a problem for my application to read XML files that don't have the additional data (which is e.g. the time the data was retrieved from the server, cache version). And of course you would also have to standardize filenames.
|
Vessper
Indicium Technologies
|
Posted - 2008.02.10 09:44:00 -
[16]
Originally by: Leyawiin As a user I wouldn't trust some online service using my API keys to retrieve data and providing it to various programs. A lot of information gets to be available for 'some' guy running the service. We don't want that!
I'd agree for the most part. If this would be done on a "global" scale, it would require someone very trustworthy to run the service and I can only really think of one person who could do that
Originally by: Leyawiin The best solution would be local storage in such a way that programs like EVEMon and EFT communicate with a local service providing them with the information they require in such a way that API keys remain invisible to those programs. All benefits mentioned earlier will be there: more applications using the same data means less load, more up-to-date data for all programs etc.
Biggest problem is interoperability between the API Service and the programs written in various languages.
Interesting topic, I'll keep thinking about this ;).
EDIT: My idea on this, please discuss.
Nice diagram!
Using the HTTPListener approach I mentioned in my above post, you could extend the diagram to include computers on a local network or even elsewhere on the internet. Requests typically made (for example) to http://api.eve-online.com/eve/allianceList.xml.aspx would be replaced by http://192.168.0.10:1234/eve/allianceList.xml.aspx instead. The same directory structure would apply for the request, it would be just the server that changed. 3rd party applications would therefore need an option to specify the server, possibly even have an alternative server in case of access issues.
I did notice in your diagram that the 3rd party applications would have no access to the API keys. I'd be interested to know what the reasoning is behind this and the sort of method you'd use to access the XML (alternative username/password I'm assuming). The only thing I can think of is that you'd only need to re-enter the API once if it changed and the username/password combo provided in the 3rd party apps can remain the same.
- - - - - -
EveHQ Character App | Item DB |
Vessper
Indicium Technologies
|
Posted - 2008.02.10 09:53:00 -
[17]
Originally by: Amida Ta
Originally by: Mdram with all the wonderful programs out there for eve that use api information, it might be a good idea if the various developers came up with a standard location to store the xml files.
that way if you use more then 1 application there is less load on the servers, all are up to date, ect
a win win situation for everyone.
The idea itself is good. However there is one more problem: Not every library saves the unmodified retrieved files as cache. My library EveAI.Live e.g. adds some additional XML tags when saving the cache files. That may not be a problem for other applications as long as they are handling the XML correctly. But it would be a problem for my application to read XML files that don't have the additional data (which is e.g. the time the data was retrieved from the server, cache version). And of course you would also have to standardize filenames.
But does your EveAI.Live library still fetch the XML from api.eve-online.com? I'm pretty sure the idea is to replace the need to visit api.eve-online.com if the required XML file has already been downloaded by another application on your system. You'd still need to have your custom XML files specific to your library.
And yes, using such a method would require standardised filenames. - - - - - -
EveHQ Character App | Item DB |
Althea Nar'agh
StarHunt Fallout Project
|
Posted - 2008.02.10 10:15:00 -
[18]
Leyawiin has a very nice idea there, of course for this to work, you need to get all the developers to make their applications be "providerthingy" aware, and going with Vesspers idea of making it work via http you don't care for the technologies each app uses...
I myself am working* on a system that would be a bit this but with much more Chiribbas idea worked into it...
*working, read: planning for now, organizing the ideas in my head :p
Anyway i think it's about time we all start to work much more together....
War. War never changes
EvE Training Monitor / iMonitor / iCEO EvE iHelper |
Leyawiin
|
Posted - 2008.02.10 12:10:00 -
[19]
Originally by: Vessper
I did notice in your diagram that the 3rd party applications would have no access to the API keys. I'd be interested to know what the reasoning is behind this and the sort of method you'd use to access the XML (alternative username/password I'm assuming). The only thing I can think of is that you'd only need to re-enter the API once if it changed and the username/password combo provided in the 3rd party apps can remain the same.
Something like this indeed. See below.
Quote:
Using the HTTPListener approach I mentioned in my above post, you could extend the diagram to include computers on a local network or even elsewhere on the internet.
Certainly
Originally by: Althea Nar'agh Leyawiin has a very nice idea there, of course for this to work, you need to get all the developers to make their applications be "providerthingy" aware, and going with Vesspers idea of making it work via http you don't care for the technologies each app uses...
Some minor changes will be required in most applications anyway since they need to point to a different address. In my opinion it's best to solve some other problems with this system:
1. API Key changes requiring updates in all applications. Imagine yourself providing a full API key to a website which at a later time you are not using anymore or just isn't what you hoped it would be. Smart as you are you change your API key. The downside of this being you have to change the key in all EVE applications. Some of these applications save all entered information based on the characters API key which causes you to lose settings or go through a big backup procedure. Of course this procedure could be made easier by all these applications making this problem slightly less 'problematic'. But why not just provide an abstraction from which available characters / accounts can be retrieved without using the API key. API key would have to be changed in one application which doesn't cause any update issues.
2. API Data Security. Mentioned by Chribba earlier in this thread was the access rights an application has towards certain XML files. As a user I'd like to have the option to reduce this to the absolute minimum. (Why would a market application need to know about my skill list)?
3. Other things. Let's be creative on this! :)
Quote: Anyway i think it's about time we all start to work much more together....
Certainly. Without one application providing this there will never be 'global' support thus making the program rather useless.
|
Goncyn
Nomadic Wayfarer Syndicate
|
Posted - 2008.02.11 00:40:00 -
[20]
There are some interesting ideas being discussed here. I'd like to play devil's advocate for a moment, if I may.
I want these programs to be useful to as much of the EVE community as possible. With that goal in mind, I think this plan of having a local "data provider" as a separate program is too complex. It mind sound like a brilliant solution from a technical viewpoint (and it is clever), but it's too much for a non-technical end user to manage. Even if users can navigate the process of installing and configuring the data provider (perhaps assisted by an installer), you're going to start running into conflicts with software firewalls, anti-virus programs, anti-spyware programs, etc. Even assuming all those things can be overcome, you're still stuck with a much more complex system to diagnose should the user say "my skills won't update." OK, well is it a problem with the data provider or with my app? Is that a question the user even knows the answer to?
Some users will say, "Oh, I don't need that, I only use EVE-Mon." Will you support that scenario? I.e. will each person still have to maintain an integrated API client, plus a client for this local data provider, so their application will work either way?
I think the most realistic plan, if we are to agree on a standardized means of updating API data, is to create a standard storage location in the filesystem and a standard naming convention. Then programs can use whichever library they want, so long as everyone a) names their XML files correctly, b) puts them in the correct place, and c) correctly checks the existing files' cachedUntil tags before making a new query. This plan makes troubleshooting easier, too, because you do not depend on any other program to behave correctly---you merely get a benefit (in the form of shared cache data) if they do.
|
|
Vessper
Indicium Technologies
|
Posted - 2008.02.11 11:45:00 -
[21]
I agree that the overall scenario is a bit more complex to diagnose in the event of some issue but I don't think it's any more "difficult" for the end user to actually setup and use. It should be a case of a) Copying a file to somewhere on your HDD and running it; b) For each account enter your API information and an associated username and password; c) Configure the API client to look at the Data Provider and replace the API information with the username and password specified in the Data Provider. That's all the basics required to get up and running. Yes, you could make it more elaborate by including filters to specify types of XML to pass but this would fall into an advanced option for the more technical minded.
Whether using this system or a standalone API client, users will still face the issues with configuring anti-virus software and firewalls. If the overall system does have issues, it should be made simple enough for a user to revert their API clients to using the standard API method rather than using the Data Provider.
The Data Provider should be an entirely optional component of a user's system. Obviously if they are using a single API client, they won't require shared access to the XML files. Of course, to use the data provider, each API client would need to be configured to use it. This (using my suggested HTTP method) would be simply a change of server address from http://api.eve-online.com to the host name or IP address of the Data Provider. All client applications would need is to be configured with an extra option to specify the server address of the API location but the default would still be Eve-o. The API client would receive the same data irrespective of the location so no additional changes would be required.
I believe that original intention for this was for programs contained on a single PC. This is the simplest and least technical method for users and they should not notice any difference. API clients would need to be re-written in places to adopt the new naming convention and locations but is shouldn't be too difficult to implement. If you are using API clients on various machines on a LAN, I think this method could still work but you'd still need an option in the API client to tell it where on the network to look (shared drive or UNC path). I'm not 100% sure what problems you would have in trying to access this shared directory from a remote location over the internet. For example, I use the same software at home and at work and I'd still like to have a shared API on my home PC.
As you can probably tell, I'm all for the separate program for the Data Provider . The Data Provider will still need somewhere to store it's retrieved XML files and the shared directory will still be useful for this. And, while the above is great in theory, it would all depend on the average user's take on it's usefulness, as well as adoption by the API client developers. - - - - - -
EveHQ Character App | Item DB |
Mdram
Caldari Crimson Rain Corp
|
Posted - 2008.02.11 16:34:00 -
[22]
hhmmm, a lot of ideas out there, all pretty good ones
but cant we start simple and come up with a common api storage location, and naming convention
naming should be easy, just the same as the download link without the aspx on the end
after that then more intersting things :) When in doubt, reload and fire another clip. |
Goncyn
Nomadic Wayfarer Syndicate
|
Posted - 2008.02.11 16:46:00 -
[23]
Edited by: Goncyn on 11/02/2008 16:55:02
Originally by: Mdram naming should be easy, just the same as the download link without the aspx on the end
It's not quite that easy. You might download the same API file using multiple different parameters (different characterIDs, API keys, etc). In my code for EVE Asset Manager I have chosen to encode the parameters in the cached file name using an MD5 hash. Here is the code from my HeavyDuck.Eve library that generates a storage path for a particular API call:
private static readonly Regex m_regexAspx = new Regex(@"\.aspx$"); private static readonly UTF8Encoding m_encoding = new UTF8Encoding(false);
private static string GetCachePath(string apiPath, IDictionary<string, string> parameters) { string mungedApiPath; string encodedParams; byte[] paramHashBytes; string paramHash; string cachePath; string dirPath;
// munge up the api path to be a file system path mungedApiPath = apiPath.StartsWith("/") ? apiPath.Substring(1) : apiPath; mungedApiPath = m_regexAspx.Replace(mungedApiPath, ""); mungedApiPath = mungedApiPath.Replace('/', '.');
// get the parameters and hash them, then stick the hash in the filename encodedParams = GetEncodedParameters(parameters); paramHashBytes = Resources.MD5.ComputeHash(m_encoding.GetBytes(encodedParams)); paramHash = BitConverter.ToString(paramHashBytes).Replace("-", ""); mungedApiPath = mungedApiPath.Insert(mungedApiPath.LastIndexOf('.'), "." + paramHash);
// make sure the directory exists before returning this path cachePath = Path.Combine(Resources.CacheRoot, mungedApiPath); dirPath = Path.GetDirectoryName(cachePath); if (!Directory.Exists(dirPath)) Directory.CreateDirectory(dirPath);
return cachePath; }
private static string GetEncodedParameters(IDictionary<string, string> parameters) { StringBuilder list; string[] keys;
// check the, uh, parameter if (parameters == null) return "";
// copy the list of keys and sort them keys = new string[parameters.Count]; parameters.Keys.CopyTo(keys, 0); Array.Sort(keys);
// build the list list = new StringBuilder(); foreach (string key in keys) { list.Append(System.Web.HttpUtility.UrlEncode(key)); list.Append("="); list.Append(System.Web.HttpUtility.UrlEncode(parameters[key])); list.Append("&"); } if (list.Length > 0) list.Remove(list.Length - 1, 1);
// done return list.ToString(); }
This code is released under the MIT License. Copyright (c) 2008 William J Rogers.
|
Mdram
Caldari Crimson Rain Corp
|
Posted - 2008.02.11 20:50:00 -
[24]
Originally by: Goncyn Edited by: Goncyn on 11/02/2008 16:55:02
Originally by: Mdram naming should be easy, just the same as the download link without the aspx on the end
It's not quite that easy. You might download the same API file using multiple different parameters (different characterIDs, API keys, etc). In my code for EVE Asset Manager I have chosen to encode the parameters in the cached file name using an MD5 hash. Here is the code from my HeavyDuck.Eve library that generates a storage path for a particular API call:
private static readonly Regex m_regexAspx = new Regex(@"\.aspx$"); private static readonly UTF8Encoding m_encoding = new UTF8Encoding(false);
private static string GetCachePath(string apiPath, IDictionary<string, string> parameters) { string mungedApiPath; string encodedParams; byte[] paramHashBytes; string paramHash; string cachePath; string dirPath;
// munge up the api path to be a file system path mungedApiPath = apiPath.StartsWith("/") ? apiPath.Substring(1) : apiPath; mungedApiPath = m_regexAspx.Replace(mungedApiPath, ""); mungedApiPath = mungedApiPath.Replace('/', '.');
// get the parameters and hash them, then stick the hash in the filename encodedParams = GetEncodedParameters(parameters); paramHashBytes = Resources.MD5.ComputeHash(m_encoding.GetBytes(encodedParams)); paramHash = BitConverter.ToString(paramHashBytes).Replace("-", ""); mungedApiPath = mungedApiPath.Insert(mungedApiPath.LastIndexOf('.'), "." + paramHash);
// make sure the directory exists before returning this path cachePath = Path.Combine(Resources.CacheRoot, mungedApiPath); dirPath = Path.GetDirectoryName(cachePath); if (!Directory.Exists(dirPath)) Directory.CreateDirectory(dirPath);
return cachePath; }
private static string GetEncodedParameters(IDictionary<string, string> parameters) { StringBuilder list; string[] keys;
// check the, uh, parameter if (parameters == null) return "";
// copy the list of keys and sort them keys = new string[parameters.Count]; parameters.Keys.CopyTo(keys, 0); Array.Sort(keys);
// build the list list = new StringBuilder(); foreach (string key in keys) { list.Append(System.Web.HttpUtility.UrlEncode(key)); list.Append("="); list.Append(System.Web.HttpUtility.UrlEncode(parameters[key])); list.Append("&"); } if (list.Length > 0) list.Remove(list.Length - 1, 1);
// done return list.ToString(); }
This code is released under the MIT License. Copyright (c) 2008 William J Rogers.
aahhh, yeah, forgot multi characters well then still simple
filestoragedir/charid just a diff sub dir for each character id When in doubt, reload and fire another clip. |
Goncyn
Nomadic Wayfarer Syndicate
|
Posted - 2008.02.11 21:03:00 -
[25]
Originally by: Mdram aahhh, yeah, forgot multi characters well then still simple
just a diff sub dir for each character id
Err, you didn't really need to quote all my code there!
Anyway, it's still not that simple, because there are different API queries with different parameters. Which is why we need to discuss how to label the files. Which is why I posted my code for discussion. ;)
|
Abbadon
Caldari Pukin' Dogs D0GMA
|
Posted - 2008.02.14 18:16:00 -
[26]
Edited by: Abbadon on 14/02/2008 18:16:32 I eventually found the post that contains the cache I use
Linkage
tl;dr version:
Cache runs on PHP, mySQL on either trusted 3rd party site or local Apache server (or even use a tiered cache approach API app >> local cache >> 3rd party cache >> EVE-O).
Any app just needs to be able to make a call to cache proxy address rather than the Eve-O server (incredibly easy to change in PHP/other uncompiled apps but would require code changes and recompile for the likes of Evemon etc)
Allows access from any location/any device/anytime
Raw xml files are stored in the mySQL database
Could easily we secured for multi user/corp use. .
|
gordon861
Minmatar PROGENITOR CORPORATION Intrepid Crossing
|
Posted - 2008.02.15 17:19:00 -
[27]
Originally by: Mdram hhmmm, a lot of ideas out there, all pretty good ones
but cant we start simple and come up with a common api storage location, and naming convention
naming should be easy, just the same as the download link without the aspx on the end
after that then more intersting things :)
Surely the best idea would be for CCP to release a small app that would cache all this data for you ?
If this was setup right you would never have to give a new program your API key again.
You just give your full key to the CCP application and the program requests the API data from there.
1. When you start a new program like EveMon you select that you have the CCP App running and then select the character by name from the list. 2. Then you tell the CCP App what parts of the API the new program is allowed to have access to.
Also the EveClient could be setup to export the API data to this App as well automatically when you change skills, or you could pull up your wallet and select 'send to API App'.
Originally by: CCP Arkanon I frown on employees being power players to the extent that their gameplay results in any sort of domination over others. I donĘt believe CCP employees should run the EVE universe. |
Amida Ta
German Mining and Manufacture Corp.
|
Posted - 2008.02.17 13:11:00 -
[28]
Originally by: Vessper
But does your EveAI.Live library still fetch the XML from api.eve-online.com? I'm pretty sure the idea is to replace the need to visit api.eve-online.com if the required XML file has already been downloaded by another application on your system. You'd still need to have your custom XML files specific to your library.
And yes, using such a method would require standardised filenames.
Sure it downloads the XML from api.eve-online. But of course it doesn't download to disk but to memory. I create cache files later from the memory representation. They are structurally identical with the files from eve-online, so other programs that can read valid xml should be able to use them just as they would with the original files.
|
Amida Ta
German Mining and Manufacture Corp.
|
Posted - 2008.02.17 13:39:00 -
[29]
Originally by: Goncyn
Anyway, it's still not that simple, because there are different API queries with different parameters. Which is why we need to discuss how to label the files. Which is why I posted my code for discussion. ;)
EveAI adds all relevant data to the filename: e.g. AllianceDataApi.xml - Does not need any additional parameters e.g. AccountDataApi.4444444.xml - Account ID e.g. CharacterAssetApi.8888888888.xml - Character ID e.g. CorporationWalletJournalApi.8888888888.1000.xml - Character and Walletaccount ID e.g. StarbaseDetailApi.8888888888.1111111111.xml - Character and Starbase ID The key does not appear there at all. I don't really like the idea to use the key to encode the parameters either because it is unsafe to use a hash algorithm to identify objects. Hashes should be used for verification purposes only. Moreover it kills your cache if you change keys.
|
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |