Pages: 1 2 3 4 5 6 7 8 9 [10] 11 .. 11 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Ramov Tinoga
Tinoga Enterprises
0
|
Posted - 2015.07.29 11:50:54 -
[271] - Quote
Thanks for the continued development, Dragonaire!
Today I installed the latest master from git and everything went fine except for one small issue. I was getting a lot of DEBUG and INFO output, so I searched for the WARNINGS that caused the verbose output and I found this:
[2015-07-29 13:21:00] yapeal.WARNING: Failed to upsert data from Eve API char/ContactList for 722849004 {"exception":"[o bject] (PDOException(code: 42S02): SQLSTATE[42S02]: Base table or view not found: 1146 Table 'yapeal2.charAllianceContac tLabels' doesn't exist at /home/scripts/yapeal-git/lib/Database/Char/ContactList.php:103)"} []
Grepping for charAllianceContactLabels, I found lib/Sql/updates/201507202210.sql , which should have created the tables on bin/yc D:I [...] , but they were indeed not there.
As bin/yc D:U claimed
Skipping SQL file 201507202210.sql since its <= the latest database version 201507202210
I manually reset the entry in utilDatabaseVersion to 201507132213 and ran the update again, which created the missing tables. On the next yapeal run, the WARNING (and verbose logging) went away and the tables were populated accordingly.
Now, I have two entries in utilDatabaseVersion (201507132213 and 201507202210). Does that mean that other updates were also possibly missed and I have to force them similar to described above, or will I be fine, now that no more WARNINGS occur? |
Dragonaire
Here there be Dragons
75
|
Posted - 2015.07.29 15:55:44 -
[272] - Quote
Ramov Tinoga - Sounds like maybe I didn't get one of the tables added to the CreateCharTables.sql file that is in the update. I'll take a look and make sure I correct it. The way it is suppose to work is the update files act kind of like a diff between the DB version that you have and what the current Create*Tables.sql create on a new install would be like but seems like in this case the update is ahead of the create . You shouldn't have to do anything else if you aren't seeing any more warnings in the logs and I'll push the updated create out either today or tomorrow as I get time.
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Dragonaire
Here there be Dragons
75
|
Posted - 2015.07.29 16:56:28 -
[273] - Quote
https://github.com/Yapeal/yapeal/issues/102
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Sona Arnst
Regnum demens Deus
0
|
Posted - 2015.09.15 11:51:33 -
[274] - Quote
Getting the bellow when running "php bin/yc D:U" and I'm no longer getting any data imported into the tables. The XML pulls fine.
DatabaseUpdater::addDatabaseProcedure
Skipping SQL file 201408281814.sql since its <= the latest database version 201507202210 Skipping SQL file 201409272333.sql since its <= the latest database version 201507202210 Skipping SQL file 201410152135.sql since its <= the latest database version 201507202210 Skipping SQL file 201411031600.sql since its <= the latest database version 201507202210 Skipping SQL file 201412130159.sql since its <= the latest database version 201507202210 Skipping SQL file 201502120216.sql since its <= the latest database version 201507202210 Skipping SQL file 201503120437.sql since its <= the latest database version 201507202210 Skipping SQL file 201505150647.sql since its <= the latest database version 201507202210 Skipping SQL file 201506131923.sql since its <= the latest database version 201507202210 Skipping SQL file 201507022249.sql since its <= the latest database version 201507202210 Skipping SQL file 201507130432.sql since its <= the latest database version 201507202210 Skipping SQL file 201507131620.sql since its <= the latest database version 201507202210 Skipping SQL file 201507132213.sql since its <= the latest database version 201507202210 Skipping SQL file 201507202210.sql since its <= the latest database version 201507202210
DatabaseUpdater::dropDatabaseProcedure
I have tried deleting all .sql files apart from 201507202210.sql but I still get the errors. |
Dragonaire
Here there be Dragons
76
|
Posted - 2015.09.18 17:59:01 -
[275] - Quote
Sona Arnst - Sorry for the late reply been busy and not checking the forums for last few days. All of the skipping messages is normal for an update it just means you already have a newer 'version' of the DB tables already. The first time you run the update when there has been a DB change it will do the one or two updates you need but skip any you have already done or for other reasons is unneeded (for example during new installs). All the update SQL file names are made up of the date and time they where created by me, so for example 201507132213 = 2015-07-13 at 10:13 pm GMT but your DB tables are already at 2015-07-20 at 10:10 pm GMT which if you look is the last one listed in the output.
If you do a fresh install and use 'php bin/yc D:I' it will also know it's at the current version. Yapeal tracks which 'version' of the DB tables is on using the utilDatabaseVersion table. Depending on how many times you done an update vs a new install you'll see one or more numbers in the table and the update always check for the highest one that it finds and adds a record for each update that it completes fully.
Hopefully my explanation help you better understand what's going on.
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Koron Eldoran
Angry Angels Constructions The Kadeshi
0
|
Posted - 2015.09.30 12:05:39 -
[276] - Quote
Can anyone tell me how this would work? I have added an API-Key to utilregisteredkey an set it to active = 1. If I yapeal calls are only the public information (mapjumps, mapkills ...) updatedt but does not update data of the API Key. |
Dragonaire
Here there be Dragons
76
|
Posted - 2015.10.01 18:08:41 -
[277] - Quote
Depends on the table but most are going to have corresponding ID columns or in the case of most of the char/corp/account tables you have the ownerID column which is based on those IDs so a simple 'delete * from yapeal.theTable where ownerID = id ' should remove anything with that ownerID
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Legedric Striker
Blue Republic RvB - BLUE Republic
62
|
Posted - 2015.12.11 07:16:59 -
[278] - Quote
Hi Dragonaire,
it's been a while and I don't know if you are still active but I seem to ran into some trouble with expired API keys lately.
In my project database several API keys seem to have expired and unfortunately Yapeal does not recognize it.
The problem is, that EVE's API only responds with error code 222 "Key has expired. Contact key owner for access renewal." even when you try to get the APIKeyInfo for a key that expired (or got deleted?) so Yapeal is not able to get the new expired date and so thinks the key is still active leading to an error everytime Yapeal tries to fetch something using that spefici key.
So my project has got well above 7k API keys in it and you can image that many people just remove their API key from their account, let it expire or whatever and all these keys lead to the following line in Yapeal's log:
[2015-12-10 23:38:02] yapeal.DEBUG: Could NOT get XML data {"exception":"[object] (Guzzle\\Http\\Exception\\ClientErrorResponseException(code: 0): Client error response\n[status code] 403\n[reason phrase] Forbidden\n[url] https://api.eveonline.com/account/APIKeyInfo.xml.aspx at /www/htdocs/w0123f51/_libext/vendor/guzzle/guzzle/src/Guzzle/Http/Exception/BadResponseException.php:43)"} []
I don't know why it is handled as "Forbidden" but that's what I see in my logs. Of course due to Yapeal's amazing speed to work on API calls I produce many many errors crawling all API keys of my project for different APIs like APIKeyInfo, CharacterSheet or SkillQueue and this leads to my IP getting blocked due to producing too many errors in a short amount of time everytime my cronjob runs the auto_magic call.
Do you see any chance on deactivating API keys once they ran into this type of error to protect peopl using your API library from getting banned due to producing too many errors?
I will have a look at Yapeal's code to see if I can do it on my own but I would feel more comfortable if you, as the original developer would implement a solution for this
Regards,
Legedric
Join R-v-B -- The MOST active PVP community in EVE!
EVE-Skillplan.net - Plan your training online using a PC, tablet or smartphone!
|
Legedric Striker
Blue Republic RvB - BLUE Republic
62
|
Posted - 2015.12.11 08:14:48 -
[279] - Quote
While I was working on a workaround I found other errors leading to the same IP ban when too many of them happen.
For example when I try to fetch a skill queue for a character I also get "Forbidden" messages every now and then.
One key I checked specifically threw this error in EVE's API: 201: Character does not belong to account.
So for whatever reason those error messages from EVE's API do not even get through to Yapeal but result in a 403 Forbidden instead. I only see these detailed error moessages when I use my browser to get the xml from EVE's API directly.
Join R-v-B -- The MOST active PVP community in EVE!
EVE-Skillplan.net - Plan your training online using a PC, tablet or smartphone!
|
Mintoko
Taedium In Perpetuam
23
|
Posted - 2015.12.11 13:12:33 -
[280] - Quote
'utilRegisteredKey' has a 'active' column and I thought that 'accountCharacters' at one time had one as well. A character on one of my accounts no longer exists and as long as the character is listed, attempts are made to pull from the API. I'd like to keep this character listed as it references other tables. Can an active column be added to 'accountCharacters' or is there something else I could do? |
|
Dragonaire
Here there be Dragons
77
|
Posted - 2015.12.11 22:02:43 -
[281] - Quote
Mintoko wrote:'utilRegisteredKey' has a 'active' column and I thought that 'accountCharacters' at one time had one as well. A character on one of my accounts no longer exists and as long as the character is listed, attempts are made to pull from the API. I'd like to keep this character listed as it references other tables. Can an active column be added to 'accountCharacters' or is there something else I could do? 'accountCharacters' didn't have an active flag but before Yapeal had 'utilRegisteredChar' and 'Corp' tables and they had active flags that could be used but with the APIs moving to 'keyID' and 'vCode' those tables needed to be dropped since everything is based on the 'keyID' now and nothing else in the APIs.
You can do what you want to do you just need to find the row in 'accountKeyBridge' that is linking the keyID to the charID and remove it. The APIKeyInfo class that manages that tables does NOT delete any old rows so references don't break but you can do so as long as you insure everything you use refs to accountCharacters table only. Note that deleting rows in accountKeyBridge only works if the charID is no longer associated with the keyID which seems to be your case. If you look at the getActiveRegisteredCharacters() method in Sql/CommonSqlQueries class you'll see how Yapeal decides which char APIs it checks. getActiveRegisteredCorporations() methods does the same for corp APIs and they both use the accountKeyBridge table to select the list of IDs so deleting the correct row there in effect makes Yapeal ignore the old char/corp you want to keep around in the other tables.
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Mintoko
Taedium In Perpetuam
23
|
Posted - 2015.12.11 22:53:31 -
[282] - Quote
Dragonaire wrote:You can do what you want to do you just need to find the row in 'accountKeyBridge' that is linking the keyID to the charID and remove it.
I can't believe I forgot about that table. Thanks.
|
Dragonaire
Here there be Dragons
77
|
Posted - 2015.12.12 05:57:43 -
[283] - Quote
Legedric Striker - I have been on a bit of a break from doing anything with Yapeal but I just starting working on it again a few days ago so you should start seeing more activity again.
How Yapeal deals with APIs errors has changed over time from having a system to deactivate stuff in some cases to the current system of just logging them. The problem with the old error system was it didn't give developers any options about what should happen or really let they know that anything had even happened. What is needed is something that is easy for developers to interface with that lets you decide what, how, or if you want to handle things like API errors. I've looked at many different ways to make it easy to allow things like this and other stuff and in the end I decided that changing Yapeal to use an event based system for stuff would be best. The only real problem is to change to one requires once again a complete rewrite which takes a lot of time The additional thing I've run into is all the existing event systems (projects) I looked at had what I felt were fatal flaws or other issues that meant I couldn't use them in Yapeal. My solution was to make my own but I didn't want something that would only be useful in Yapeal since I believe in writing reusable open source code is important. For anyone that is interested you can see what I came up with at https://github.com/Dragonrun1/event-mediator.
I also decided that with this re-write I needed to see if I couldn't make the job easier since re-coding everything for over 100 DB tables and the required classes in Yapeal is really a kind of overwhelming task for a single person and from past experience I knew I would get little help doing it. There is also the fact that more APIs keep being add (which is great) but since Yapeal requires adding one or more classes, SQL, XSD, etc each time it can take a while for me to add them to Yapeal which is not great for anyone trying to use it. Even just a simple new rowset API involves a lot of manual work every when doing copy and paste and it's easy to make mistakes as you can see going through the commit history. What I've been working on is something that can automatically write most of the simpler API stuff and just leave the one off type APIs like charactersheet etc for me or someone else to write. Of course writing software to write other software can at times be a little challenging and some things that have been going on in my RL have unfortunately kept me busy and not able to get as much done as I would have liked .
Any way to cut this post off before it becomes even longer than it is you can follow the progress of the next version of Yapeal at https://github.com/Yapeal/yapeal-ng. I made it into another project for now to make it easier for me to work on while mobile etc when I have a chance. Understand it's very much broken and not really working but everyone is welcome to look at it and make comments and suggestions to improve it.
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Dragonaire
Here there be Dragons
77
|
Posted - 2015.12.23 07:41:53 -
[284] - Quote
Hi all, A little pre-holidays cheer for those of you trying out yapeal-ng. I've pushed all of the stuff I've been working on out for you to take a look at. It's still all Alpha quality and not for production yet but it does try to at least create stuff now and the normal retrieve and preserving works. Make sure you check your yapeal.yaml file as there are many changes to the settings in it. Only APIs the create stuff really works for are simple Rowset types so still a lot of work to do but at least you can start seeing how it'll work. You can also get a better idea how the new event stuff works.
Legedric Striker - You should take a look at the events and give me some ideas what kind of events you'd like to see for the API server errors and I'll look at adding them in. If the only ones that you want to deal with are the XML error ones processed in Xsd/Validator::ProcessEveApiXmlError() then triggering some events there shouldn't be hard that your app can then subscribe to. If not we'll need to look at the event system in Guzzle as well to see if it'll be possible to maybe add some kind of wrapper around them so they can be integrated.
Anyway as always thank you for using Yapeal and may your holidays be great, Dragonaire
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Dragonaire
Here there be Dragons
77
|
Posted - 2016.01.05 03:27:05 -
[285] - Quote
Pushed large update to yapeal-ng alpha for those following it. Please try out the new bin/yc E:C command and let me know how it's working for you. To make development easier I've changed it to only work with values only(Elements without attributes/children) or rowset type APIs or APIs that have both. This should cover most of the existing APIs (80%+) but not complex APIs like Char/CorpSheet or AssetList etc. I may in the future trying adding stuff to handle the more complex APIs but want to get the basic ones right before moving on. Note that it wouldn't overwrite exist files in the EveApi/Sql/Xsd directories so if you are want to see any change to the creator output files you'll need to delete anything from prior runs for the APIs you are looking at. Make sure you report any bugs or errors you notice. Please if you have access to lots of APIs keys it would be a big help if you could take some time to test thing as I've only got a couple to work with on from my own account and it's not very active so many of the APIs return basically empty results so it's easy to miss problems. I'm mostly looking at the create process itself but reports of problems when running Yapeal like normal on accounts with newly created API stuff is also welcome.
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Dragonaire
Here there be Dragons
78
|
Posted - 2016.02.02 03:32:59 -
[286] - Quote
Okay been doing a lot of work on Yapeal-ng and pushed out result of first mass create with the new 'yc E:C' command. Some of the SQL and XSD still need hand optimization but what APIs are there should be working. It is still not ready for production but it's ready to be tested by someone other then me for sure. I'd really like to hear from some developers that use the existing Yapeal with 10 or more API keys and hear your feedback. If you can test it in parallel against the same setup with a second DB you currently use and report any bugs or other things you notice like speedups/slowdowns etc it would be very helpful. Once I've completed the SQL/XSD optimization stuff I'll start work on the more complex APIs that can't be auto-created. I'll probably just be doing them by hand but may try to make things a little smarter so the command can do some of the heavy lifting but either way I'll get some of the more useful ones done like characterSheet etc which most people need for their apps once I'm sure all the bugs/issues are worked out using the simple APIs.
So to sum it up I need some testers for the first public Beta version before I can really continue on and be ready to start putting out any RC releases on the way to a production ready release.
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Moshta Khadiija
Spai Finder
0
|
Posted - 2016.02.02 04:09:51 -
[287] - Quote
I'm already using another PHP library to deal with everything OTHER than the alliance listing, but it looks like your stuff is exactly what I'm looking for in this case. I take it Yapeal is geared more toward the universe-esque endpoints, like sovereignty, etc.?
|
Dragonaire
Here there be Dragons
78
|
Posted - 2016.02.02 23:39:22 -
[288] - Quote
Actually it meant to deal with all of the APIs but because it acts more like a XML API to database converter than just a simple wrapper for a network library it makes dealing with some APIs easier. As an application developer which would you find easier to use some inconsistent raw data that you need to parse yourself or have generally well structured database tables full of the information you'll need so you just have to write the queries to extract what you are looking for? If the application you are making only needs stuff from a couple of the APIs all the existing API libraries do a good job and they all can work in any application but as the application grows more complex through adding more APIs etc the work load IMHO goes up much faster with the other libraries as they have a much lower level interface you are working with vs Yapeal where the database is the interface.
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Dragonaire
Here there be Dragons
80
|
Posted - 2016.02.27 06:32:57 -
[289] - Quote
Hi all just an update to let everyone know I haven't forgot about Yapeal just been busy with other things. For anyone that's interesting in understand more about how Yapeal-ng works you might look at some of the new docs I've been working on for one of my other projects Event-Mediator. I use some code from Yapeal-ng in the example since it uses Event-Mediator for the logging as in the example but the other place it's used is in the main event loop which is at the heart of Yapeal now. While write about Event-Mediator I got to thinking about some other stuff I can do to improve Yapeal as well so look for some upcoming updates there too.
That's all for now as always thanks for using Yapeal, Dragonaire
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Dragonaire
Here there be Dragons
80
|
Posted - 2016.05.17 16:17:00 -
[290] - Quote
Just wanted to let everyone know I've not forgotten about Yapeal but some RL issues like having to move have been getting in the way. I'm hoping to have more time in a couple of weeks.
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
|
Tiberius Zol
HildCo Interplanetar Villore Accords
73
|
Posted - 2016.05.17 19:43:27 -
[291] - Quote
Take your time mate. We will wait. :)
Mr. Tibbers on twitter: @Mr_Tibbers
Mr. Tibbers Blog: www.eve-versum.de
|
Dragonaire
Here there be Dragons
80
|
Posted - 2016.06.29 00:11:20 -
[292] - Quote
Just a quick bump and note to say I'm still working on Yapeal-ng.
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Dragonaire
Here there be Dragons
81
|
Posted - 2016.07.07 20:34:19 -
[293] - Quote
Couple new things for people to look at for Yapeal-ng. First Yapeal-ng now has it's own twitter account @Yapeal_ng so check it out. I just added a poll question there as well to get some feedback to decide on future road-map planning so please vote. Took a little break from regular programming as well to make some better/newer artwork to use with Yapeal-ng as well. You'll find what I have going on in new media/ directory that I just pushed out.
As always thanks for using Yapeal, Dragonaire
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Dragonaire
Here there be Dragons
82
|
Posted - 2016.07.10 05:22:46 -
[294] - Quote
Pushed out lots of changes to Yapeal-ng check them out also check out the new @Yapeal_ng on twiitter.
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Dragonaire
Here there be Dragons
84
|
Posted - 2016.07.18 14:31:55 -
[295] - Quote
Just to let everyone know that are following / waiting on me to complete Yapeal-ng I've decided to change the PHP requirement to version 7.0. The original Yapeal will continue to work with older versions and I have stopped development on it. If someone else is interested in picks up develop on it please contact me. I decided I'm tired of living in the past programming wise with the project so I'm not any more. I'm in the process of changing everything over to use scalar type hints and other things that should make the code safer and in some cases allows removing a lot of legacy code that was needed to maintain compatibility etc with older versions. Most of you can probably just switch to PHP 7.0 in your applications with no noticeable difference except it might run a little faster. There is lots of help available online if you have any problems. I also will try to make some time to help you if its related to Yapeal or Yapeal-ng as well.
As always thank you for using Yapeal-ng, Dragonaire
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Salgare
Satan's Gut
2
|
Posted - 2016.07.18 16:56:15 -
[296] - Quote
Hey Dragonaire,
I was rooting around your github site looking to see how you configured a couple things. I read the install.md but did not see what I was looking for.
1. How do you determine what endpoints you are going to hit and move to DB? 2. It seemed the schema did not have tables for user api keys, scopes or such, are you using SSO at this time? If so, how did you handle the authentication, scopes etc. ? |
Dragonaire
Here there be Dragons
86
|
Posted - 2016.07.19 05:14:42 -
[297] - Quote
Need to look in the util tables. utilEveApi has an active column to turn the APIs on or off Yapeal-ng wide then you add your API kayID etc to utilRegisteredKeys for the char, corp, or account key you have. There is also a active column as well as activeAPIMask value which is bool '&' with the mask from the key itself to allow you to turn things on or off on a pre-keyID basis. Those are really the only tables that an application will need to write to in most cases. Its sometimes useful to clear the utilcachedUntil table during development but generally not needed in production.
Yapeal and by proxy Yapeal-ng have been around long before CREST even existed so it uses keyID and vCode. There was an even old system from CCP which has since been dropped which is what Yapeal originally used before that. I believe you can get a keyID and vCode from CREST that can be used with the XML APIs but I don't have any experience with how it works etc since my direct experience with CREST has been limit plus they added the tie in with XML API only a little while back I believe.
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Dragonaire
Here there be Dragons
88
|
Posted - 2016.07.22 14:33:39 -
[298] - Quote
Small update I've been working on updating some of my other projects that Yapeal-ng uses for PHP 7.0 as well. Been slowed down a little by some needed updates from other outside tools there but still limping along getting it all updated so I can get back to working on Yapeal-ng instead.
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Dragonaire
Here there be Dragons
89
|
Posted - 2016.07.25 19:24:49 -
[299] - Quote
Updated one of the tools used by Yapeal-ng thought I'd let people know here as it can be useful for application developers as well. http://www.phpclasses.org/package/8912-PHP-Get-the-full-path-of-files-relative-to-root.html
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
Dragonaire
Here there be Dragons
89
|
Posted - 2016.08.02 19:47:04 -
[300] - Quote
Updated another tool used in Yapeal-ng for PHP 7.0+ thought I'd share it as well for anyone that might want to use it in their own applications. http://www.phpclasses.org/package/9568-PHP-Emit-and-listen-to-events-using-a-mediator-object.html
Currently WIP on doing updates for PHP 7.0+ in Yapeal-ng and a little refactoring that's needed to add on PHPSpec examples (tests) as well.
Finds camping stations from the inside much easier.
Designer of Yapeal for the Eve API.
Check out the Yapeal PHP API Library thread.
|
|
|
|
|
Pages: 1 2 3 4 5 6 7 8 9 [10] 11 .. 11 :: one page |
First page | Previous page | Next page | Last page |