EVE Technology Lab

After running some testing:

• Method: POST (form-encoded) Compression: None Result: OK
• Method: POST (form-encoded) Compression: GZip Result: OK
• Method: POST (form-encoded) Compression: Deflate Result: OK
• Method: POST (entity) Compression: None Result: OK
• Method: POST (entity) Compression: GZip Result: OK
• Method: POST (entity) Compression: Deflate Result: OK

EMDR will be added in EMUU endpoints in few.

Yeah, it can run on Windows, but considering that you've got a lot of extra work to do to install a compiler on Windows, it's probably not going to be something I want to officially support, even though it should be doable (in theory). As you saw, there are quite a few dependencies, gevent and libzmq being the ones needing a compiler.

I'll eventually write detailed instructions for Linux (which would be generic enough for the Mac OS users to follow), though. Once I've got the last few code rough spots fixed up, documentation will become my focus for the rest of the week. This will help make it possible to recruit people to run relays.

Something I have been looking into pyzmq-static:

http://pypi.python.org/pypi/pyzmq-static/

This is currently running an older version of pyzmq that isn't compatible with EMDR, but that bundles libzmq, which would reduce some of the annoyances you ran into.

Nah - my stuff is in ORD for Rackspace and EWR (newark) for Linode so you'd have physical redundancy.

Unfortunately my friend, although it's in the repo, it's not included in the distributed msi or source zip files.
Never the less I managed to get the source code from the repo, build it, install it but I can't make the EMDR source code to see the package. Now I get "ImportError: No module named green". Every other requirement is installed and working.

I think they're approaching a release, so hopefully it won't be as painful for much longer.

This will eventually be posted to the unified upload interchange format thread when it's in better shape, but I'm breaking all of the market data structures, along with serializers and de-serializers, out into their own project. Initially, this will just be for the unified format, but it'll be maintained in a manner to make it easy to drop others in if something new and better comes along.

https://github.com/gtaylor/EVE-Market-Data-Structures

There's going to be some pretty heavy lifting going on with this over the week, so I wouldn't use it for anything yet. It doesn't support the absence of orders/history for a given item+region ID combo yet, but that will be addressed shortly.

I'll probably be doing some pretty heavy re-working of what I have so far, because it made some bad assumptions. However, I'm hoping to have it in good shape and unit tested this week.

Excellent, let me know if you see anything wrong. I'd like to have the data as scrutinized as humanly possible so we can catch anything before reaching "1.0".

I need to do some more research but I'm seeing some inconsistencies in the data. Unfortunately I didn't have my script save off the original data (a mistake soon rectified) for comparison but here's an example:

mysql> select * from marketdata where orderID = 2532530253;
+-------+-----------------+---------------------+----------+--------+-------------+-----------------+---------------+---------------+-------+------------+-----+---------------------+----------+-----------+---------------+------------+---------------------+
| id | uploadKeys | generatedAt | regionID | typeID | price | volumeRemaining | volumeEntered | minimumVolume | range | orderID | bid | issueDate | duration | stationID | solarSystemID | suspicious | dateAdded |
+-------+-----------------+---------------------+----------+--------+-------------+-----------------+---------------+---------------+-------+------------+-----+---------------------+----------+-----------+---------------+------------+---------------------+
| 27452 | Eve Addicts | 2012-05-18 00:00:52 | 10000043 | 30050 | 50001057.01 | 2 | 5 | 1 | -1 | 2532530253 | 1 | 2012-05-18 00:00:41 | 90 | 60008494 | 30002187 | NULL | 2012-05-18 10:33:50 |
| 31771 | EVE Market Data | 2012-05-18 15:34:17 | 10000043 | 30050 | 50001057.01 | 2 | 5 | 1 | -1 | 2532530253 | 1 | 2012-05-09 18:14:10 | 90 | 60008494 | 30002187 | NULL | 2012-05-18 10:35:14 |
| 45968 | EVE Central | 2012-05-18 15:34:55 | 10000043 | 30050 | 50001057.01 | 2 | 5 | 1 | -1 | 2532530253 | 0 | 2012-05-18 04:43:41 | 90 | 60008494 | 30002187 | NULL | 2012-05-18 10:35:52 |
| 48411 | EVE Central | 2012-05-18 15:34:56 | 10000043 | 30050 | 50001057.01 | 2 | 5 | 1 | 65535 | 2532530253 | 0 | 2012-05-18 04:43:41 | 90 | 60008494 | 30002187 | NULL | 2012-05-18 10:35:52 |
+-------+-----------------+---------------------+----------+--------+-------------+-----------------+---------------+---------------+-------+------------+-----+---------------------+----------+-----------+---------------+------------+---------------------+
4 rows in set (0.09 sec)

The problem is the bid flag - this is just a random example of the problem - but the first two orders are showing as bids but the latter two from Eve Central are not. I'm less concerned about the inconsistency on the range field since i'm not sure what use it is at this time. And yes, it's harder to read that table without a fixed-width font but [code] doesn't seem to work here.

Yikes, that is probably a silly mistake in my EVE Central SMTP feeder. I've tweaked this, can you see if it's acting as expected for you now?