Zanix said in this thread/post n°6:

zanix wrote:Updated svn[1792]
It does appear that DS was going to query an item db for info, but all I see is comments about it
....

DS is/was right.
If an item has is “isSocketable”, then this can be easily detected as long as there is a non-occupied.
This is detected with the preg_match ['tooltip_preg_emptysocket'] filter. It will dig up the socket color.
But the very moment a socket is equipped with a gem, then that the socket colour information is lost.
So, it’s not possible anymore to detect if the colour of the inserted gem(s) meet the “Socket Bonus” requirements.


What does this mean?
A solution might be scanning the item table to see if the same item exists without any gems inserted. I consider this chance to small.

Well, the item name is known, as is the item number – the only solution is, as DS already stated: we’ll have to make a request to an external database.
This concept isn’t new. For myself, I’m using already a site-addon like itemstats that does this quiet well – it includes “search by number” and “search by name” for many WoW public item database.
When the item is found, it should be stored in a local table. Next time the tooltip is being generated, the “empty item info” would be found immediately.

In the beginning, this solution, the roster would make some “foreign database calls”, but this will nearly stop, as not everyone loots Socketable items every day.

This solution won’t be ready for the WowRoster 2.0 – it isn’t even on it's roadmap. But it would be a nice thing to include, because pretty straight forward to code.
I'll have try to make a version of item.php that uses this solution.
If it works, the installer should install 'yet another table',
The CP should include a section to shut down (option by default) this solution.
One function should be written that and inserted that the last two occurrences of $this->isSocketable = true;

Remember, all this to decide if the Socket Bonus for an item applies, when the gem colour condition is met, or not.

DS already made a table called webcache for this purpose, I remember him asking if he could add it

I think the solution might be to query the armory, I think there was beginnings of code to do this, but DS never finished it

zanix wrote:DS already made a table called webcache for this purpose, I remember him asking if he could add it

Yep, I figured that out, the webcache table seems to be designed to store the information we need.

I think the solution might be to query the armory, I think there was beginnings of code to do this, but DS never finished it

One thing for sure :
DS should have met Poetter !!

Using the lib/armory.class.php class/functions give me a simple:
http://eu.wowarmory.com/item-tooltip.xml?i=28518 seems just perfect.
even a
http://eu.wowarmory.com/item-tooltip.xm ... ocale=frFR
and a
http://eu.wowarmory.com/item-tooltip.xm ... ocale=deDE
works well.

I didn't think that this was that easy.

QUESTION : for gem slots being recognised, item.php should be patched (inserting a function on two places).
=> Would it be best to fill the webcache array while uploading/importing a character with CP.lua, meaning that we need and update_hook.php = is a simple roster addon?
This addon should fill the webcache table, and a new function, present in item.php will check the "gem colour correctly inserted bonus".

When working like this, the addon 'gem-socket-checker' can be shut down easily without disturbing roster functionality.

Are these thoughts ok; are there any other proposals, suggestions or ideas?

The update process already takes quite a bit of time

Querying the armory would likely push the update process into a timeout
I think the info should be fetched when the item is requested for view
Meaning item.php should handle this

In both cases, checking the objetc/items with gem sockets that fires a call to a remote site [Armory or what ever] only takes place when then item ins't already present in the local database.
So, in the best case, a simple SELECT with a postif result with stop the code.
Worst case : a remote connect to a foreign site will be executed.

I understand that you want to keep this out of the update process.
Simply showing a character's equipement page (or banks & sacs) is less 'mission cricical', I agree.

Thanks for making this clear.

I start coding a gemsocket.php file

Nothing to do with gems, but when I have something that pulls item toolinfo from the Armory, this could also be used by the Vault journal, that is plagued with item ID 'only' because the withdrawn objects are gone.

Am I right ? The info should be cached in the same web cache table ?

It could indeed