Created attachment 603
patch implementig the proposed code (untested!)

I have made the code proposed above into a patch against the current CVS HEAD.
I have *not* tested this, so your milage may vary.

attachment Database.php ignored as obsolete

MediaZilla wrote:

Test-Wiki for this patch, see at http://www.wikipage.de/en/index.php/User:FireDragon (english-page) and
http://www.wikipage.de/de/index.php/User:FireDragon (german-page)

zbigniew.braniecki wrote:

patch v2

Hi.
We're working on similar issue for Developer Mozilla Center
(https://bugzilla.mozilla.org/show_bug.cgi?id=296085).
I wrote a patch for MediaWiki 1.4.5, and it seems to work better than one
attached here.
The patch from this bug still has a bug with strpos('.',$name) - copare to
http://pl.php.net/manual/en/function.strpos.php .
Our patch also solves the issue with table prefixes.

Can I ask for some kind of review or sth?

attachment bug-296085-2.patch ignored as obsolete

gangleri wrote:

Halló!

I was wondering why we could *not* lock the database for one of the 6 wikis at
http://www.wikipage.de/en/index.php/Main_Page . I understand that the user table
is shared and this could cause some problems.

Please verify if the database can be locked for individual wikis. If so what
would be the procedure?

Regards Reinhardt [[user:gangleri]]

zbigniew.braniecki wrote:

patch v3

I updated the patch. There was a small bug which made unable adding someone to
admins. Now its fixed.

attachment bug-296085-3.patch ignored as obsolete

zbigniew.braniecki wrote:

patch v.3 against the trunk

This is the patch against the trunk.

attachment bug-296085-3-trunk.patch ignored as obsolete

zbigniew.braniecki wrote:

FYI: This patch is widely used on developer.mozilla.org and it works ok.

gangleri wrote:

Hallo!

I would like to add a small note based on "history" as the test configuration
for 6+2 languages was lost.

Please check if you need to apply the patch *before* users log in / sign in to
wikis newly added to the wiki group.

What happened:
There where test wikis using different LanguageXx.php as de en eo it ja ro and
about 20 registred users.
Then two new wikis fr and la where set up.
The seccond user signing in to the new wikis (user id #2) from fr and la was not
identical with user id #2 from the first wikis.
User id #2 made some hundred edits.
Then the patch was applied.
This was resulting in the strange situation that user id #2 from the first group
of wikis was the creator of the pages, had them on his watchlist etc. etc.

Recommended workaround. No user should sign in before the (original / earlier)
patch is applied to a newly added wiki.

Sorry for not reporting this before.

Best regards Reinhardt [[user:gangleri]]

zbigniew.braniecki wrote:

Well. This functionality should be used with new wikis. For already existing
wikis I wrote a migration patch -
(https://bugzilla.mozilla.org/attachment.cgi?id=189544)

zbigniew.braniecki wrote:

patch ver 4

Patch for trunk with fixed whitespaces and var names.

attachment bug-296085-4-trunk.patch ignored as obsolete

Looks good except the user_newtalk bit which appears clearly incorrect. Newtalk is
per-wiki, since talk pages are per-wiki. Is there some reason for that, or could it
be cleaned up?

Removing patch, need-review keywords.

zbigniew.braniecki wrote:

no problem, I wasn't sure how it should be solved. Can we check in this patch
(without user_newtalk) then?

zbigniew.braniecki wrote:

patch against 1.6.5

patch updated to 1.6.5.

It *has* review+, what blocks us from checking it in?

attachment bug296085-4.patch ignored as obsolete

Doesn't appear to work (tried merging on trunk).

I set:
$wgSharedDB = "onefive";
(left $wgSharedDBPrefix null)

Queries end up with bogus escaping like this:
... FROM `onefive.user` WHERE user_id = '1' LIMIT 1

which results in SQL errors.

zbigniew.braniecki wrote:

investigating

zbigniew.braniecki wrote:

Brion: can you give me steps to reproduce it? It works for me.

1. Merge patch on trunk
2. Leave all table prefixes blank as default
3. Set $wgSharedDB to "shareduser"
4. Try to log in

kabooms like so:
SELECT user_id FROM `shareduser.user` WHERE user_name = 'WikiSysop' LIMIT 1

zbigniew.braniecki wrote:

patch against 1.6.5 v2

ouch! Thanks, I screwed last patch. It missed } else { statement. Fixed in this
patch

attachment bug296085-5.patch ignored as obsolete

zbigniew.braniecki wrote:

patch against 1.6.5 v3

grr, removed debug value from DefaultSettings.php

attachment bug296085-6.patch ignored as obsolete

This looks like it should work, though it'll be incompatible
with existing use of a common table prefix for all databases.
Might it be cleaner to let it use the default table index
if $wgSharedDBPrefix isn't set?

gregory.szorc wrote:

I could really use the latest version of this patch in the trunk. It definitely
makes sense to be able to support both a shared user database AND a shared user
table.

I could also use a shared user_groups table. However, once you've done 2, you
might as well do all. Perhaps there is a need for a run-time hook that can
change the table names based on global variables. This could be used for other
tables, like interwiki, math, etc.

gregory.szorc wrote:

Allows you to define which tables are shared

This patch trumps the current purpose of this patch by allowing you to
explicitly define which tables are shared. It allows you to specify an
optional prefix for the shared tables as well as an optional other database.

It makes sense to share more than one table because there are multiple tables
that could be shared between a wiki family. These include:

user, user_groups, ip_blocks, math, interwiki, and possibly others.

attachment sharedTables.patch ignored as obsolete

zbigniew.braniecki wrote:

The only difference between my patch and Gregory's is the ability to select
tables to share. I'm not convinced if we really need this, but if we do I can
review this patch.

Brion: please, make up your mind, what do we want from this patch, I'll try to
make sure we have it and let's get it into trunk, it lasts so long in the
pre-checkin universe.

It needs to 1) work and 2) not break for our existing users
who use this feature, such as Wikia.

gregory.szorc wrote:

To be honest, I never reviewed my patch, but I think it should work. It is
small enough to debug easily. I can actually test it later today.

Anyway, the current method ($wgSharedDB) is marked as EXPERIMENTAL. IMO, this
could be deprecated and people shouldn't complain because they were using an
EXPERIMENTAL feature. In reality, I know, I know...

The transition from wgSharedDB to my patch just involves changing a variable in
LocalSettings.php. Also, it would be possible to have my patch look for the
presence of $wgSharedDB. If it is set, $wgSharedTables is automatically
populated with 'user'.

I still argue that we need the ability to share any table we want. Obviously,
we would never share some tables, like page, etc, but you never know who has a
usage case for sharing a table, especially when it comes to custom extensions.
If you are opering multiple wikis outside of the same database, it really
doesn't make any sense to have separate math, ip_block, and interwiki tables (at
least in some cases).

zbigniew.braniecki wrote:

Gregory: I do agree with you, the problem is how to handle it smoothly.

I'll take a deeper look today, and try to come with some solution.

gregory.szorc wrote:

Share any table (against r15716)

This is my previous patch except it will support users of the old method
($wgSharedDB) without any configuration changes. This patch is still untested.

attachment patch ignored as obsolete

gregory.szorc wrote:

Share any table (against r15716)

Added forgotten around table names. I've tested this against 1.7.1 and it
works fine. Currently sharing user, user_groups, interwiki, and math tables
between two wikis ;)

attachment patch ignored as obsolete

I'm a little leery of this kind of magic:

+if ($wgSharedDB && !$wgSharedTableDatabase) {
+ $wgSharedTables[] = 'user';
+}

Configuration settings that change violate the principle of least surprise;
while we have a few such settings already, I'd prefer not to add more if it
can be avoided more simply.

Perhaps it would be cleaner to just set $wgSharedTables = array( 'user' ) as
the default, and continue using $wgSharedDB cleanly?

gregory.szorc wrote:

If we default $wgSharedTables to array('user'), how do we prevent false
positives? if (in_array('user', $wgSharedTables) && !$wgSharedDB) ?? That is
just as hacky.

Since $wgSharedDB is still experimental, how about we just break it by doing the
following in Setup.php:

if (isset($GLOBALS['wgSharedDB'])) {

throw new MWException('wgSharedDB is no longer supported.  See $wgSharedTables.');

}

Anybody upgrading his or her wiki will immediately know what the problem is.
There can't be that many people actually using $wgSharedDB. Those who do
probably have the resources to test upgrades before putting them in production.

zbigniew.braniecki wrote:

Can you elaborate more on "false positives"? Where would they appear?

I fail to see how using the presence of a normal, existing, already used
in production by the second-largest known MediaWiki user, configuration setting
as a guard condition in the one function that would use it constitutes being
"just as hacky" as silently changing the configuration settings based on the
presence of another setting (which could be set by a user if register_globals
is on given its removal from DefaultSettings.php, potentially breaking things
interestingly).

zbigniew.braniecki wrote:

I agree with Brion here.

btw. Brion, who do you call second-largest MediaWiki user? :> On which position
MDC is? ;)

gregory.szorc wrote:

OK, so we support wgSharedDB alongside wgSharedTables. I argue that putting
code in Setup.php, as is the case with the current patch, is better than in
tableNames() because code in Setup.php only gets executed once. It doesn't make
sense to evaluate the same logic for every call of tableNames() when it could be
done once.

Perhaps we should also add a trigger_error(foo, E_NOTICE) if wgSharedDB is on,
so we can warn people they are using a deprecated method. In some later
release, wgSharedDB throws an exception. In an even later release it is removed
altogether, along with the hackish Setup.php code.

This satisfy everyone?

zbigniew.braniecki wrote:

I'm lost.

As far as I understood the issue, Brion asked you why do you want to do this:

+if ($wgSharedDB && !$wgSharedTableDatabase) {
+ $wgSharedTables[] = 'user';
+}

instead

+$wgSharedTables = array('user');

And you are answering about modyfing code in tableNames() function...

gregory.szorc wrote:

If $wgSharedTables defaults to array('user'), every wiki powered by a source
tree will have the user database shared by default, using the current patch.
This is like setting $wgSharedDB = true in DefaultSettings.php, a departure from
the status quo.

$wgSharedTables should be an empty array by default.

Perhaps the patch for Setup.php should be:

+if ($wgSharedDB && !in_array('user', $wgSharedTables) {
+ $wgSharedTables[] = 'user';
+}

Effectively reads:

If using old method of sharing user table and we haven't been told to share the
user table using new method, then share the user table.

I answer about $wgSharedDB in tableNames() b/c if we are trying to deprecate its
usage, we should isolate the variable to somewhere where it can easily be
removed. Setup.php is that place. Being a part of logic in tableNames() is no
place for a deprecated variable. It will be much easier to deprecate its
functionality in Setup.php than revisit the logic in tableNames(). This is also
contingent on deprecating $wgSharedDB. Even then, I still argue it is less
hackish to have a configuration variable change in Setup.php than to support two
configuration variables using more complex logic in tableNames() than a single
variable would require. Supporting two variables in tableNames() slows things
down. Would you rather compute something once per session, or at least once per
query?

(In reply to comment #36)

If $wgSharedTables defaults to array('user'), every wiki powered by a source
tree will have the user database shared by default, using the current patch.
This is like setting $wgSharedDB = true in DefaultSettings.php, a departure

from

the status quo.

The status quo is that the list of tables to share is hardcoded as just
"user". If this were changed from a hardcoded list to a changeable list,
perhaps called $wgSharedTables, then it could be increased or decreased at the
will of the site administrator.

For all intents and purposes this setting *already exists* in the code, it's
just hardcoded in a function.

There is no reason to deprecate the usage of $wgSharedDB and I would not
recommend doing so. You need both settings anyway, so why rename one of them
when there's no reason to?

zbigniew.braniecki wrote:

I don't see a problem here. We can check if wgSharedDB is empty or not. If it's
not, then yes, by default we want to share 'user' table. If it's empty, then we
don't want to share anything.
29 that
I'm not sure why you want to deprecate wgSharedDB, and I'm not sure if we agreed
on that, at least I don't see Brion's comment saying that. In fact Brion said in
Comment 29 that he prefers (as well as I do) to keep wgSharedDB and use the
$wgSharedTables = array('user'); method.

Could you please, explain once more why do you want to deprecate it?

gregory.szorc wrote:

In response to #37 and #38, the reason to deprecate wgSharedDB is because
wgSharedTables supercedes its functionality. wgSharedDB gives you control over
1 table. wgSharedTables gives you control of any. It is bad coding to have two
configuration variables that do almost the same thing, especially when one
variable covers the entire functionality of another.

You can keep wgSharedDB if you want, but it shouldn't be used in logic anywhere
in the code, except for where its functionality is swallowed up by the larger
variable, wgSharedTables.

Er, no.

$wgSharedDB indicates which database, if any, the shared tables are pulled
from. Being empty means that the shared tables are used in the local database
(which we can think of as meaning that they aren't shared, or that the sharing
system is disabled, but it's all the same thing really).

In your patch, $wgSharedTables is a list of which tables are shared. It does
not perform the function of $wgSharedDB, nor does it replace it in any way.
Rather, it replaces the hardcoded check for the 'user' table name with a
customizable list.

In fact, your patch renames $wgSharedDB to $wgSharedTableDatabase. This
indicates to me that you do agree that its function is required.

If you agree that it is a required function, then I'm left asking why you want
to rename it?

zbigniew.braniecki wrote:

Gregory: But I do not understand why do you want to substitute wgSharedDB with
wgSharedTables...

wgSharedTables is a list of tables that are shared with common DB.
wgSharedDB is a name of database where those common tables are stored.

You want to deprecate wgSharedDB and instead add $wgSharedTableDatabase which
does exactly the same. I see no goal in it.

In result we'll have 3 variables. One to decide which DB stores common tables,
second to decide what prefix shared tables use, and third to decide which tables
are shared.

Maybe it would be simpler to create map them? Sth like:

$wgSharedTables (

'user' => 'dbname.foo_user'

,'foo2' => 'db2.prefix_foo2'
);

This way:

1. We limit the amount of variables
2. We're flexible like hell, you can keep every table in different database and

with different prefix
:)

gregory.szorc wrote:

I like the mapping idea in #41. Concatenates everything down to one variable.
Makes it much simpler. Lot more flexible too.

I proposed renaming wgSharedDB to wgSharedTablePrefix b/c, although the variable
names reflect the same thing, the behavior of the variable is not identical.

wgSharedDB as it currently is coded says, "I want to share the user database.
Here is the database where it is located."
wgSharedTableDatabase as coded in my patch says, "If you are sharing tables,
here is the database in which these shared tables can be found"

wgSharedDB is explicitly tied to the user table in the current code. It doesn't
sit right with me that this association is altered. The behavior of a
configuration setting should be constant between releases. This is why I think
it warrants a variable name change. That being said, wgSharedDB is
*experimental* and should be used at one's own risk. Perhaps we *can* get away
with altering this configuration setting's behavior.

Also, there is a logic error in my Setup.php component of my patch. Should be
something like,

+if ($wgSharedDB) {
+ $wgSharedTableDatabase = $wgSharedDB;
+
+ if (!in_array('user', $wgSharedTables)) {
+ $wgSharedTables[] = 'user'
+ }
+}

Of course, this doesn't matter, b/c the mapping proposal is infinitely better.
When will I see a patch?

zbigniew.braniecki wrote:

Brion: what do you think?

The only think that make me not confident about my solution is that it requires
you to name the database and prefix eachtime while in 99% of cases it'll be the
same...

gregory.szorc wrote:

If the db and prefix is the same in 99% of the cases, then any wise programmer
would just write:

$prefix = 'mydb.myprefix';

$wgSharedTables = array(

'user' => $prefix . 'user',
'interwiki' => $prefix . 'interwiki',
...

);

It is a small inconvenience for better flexibility.

gregory.szorc wrote:

Shared tables as array map (against r15780)

Implements $wgSharedTables as an array that maps a table name to a the desired
name.

Deprecates wgSharedDB because this variable is no longer needed since there is
no such thing as "one shared database." The map can actually map tables to
multiple databases, if desired.

In interest of continuity, if wgSharedDB is present and no map for the 'user'
table is set, then 'user' is mapped to $wgSharedDB . $wgDBprefix . 'user', just
like current behavior.

attachment patch ignored as obsolete

angryxpeh3 wrote:

Can you also look to Bug 7247 ? It seems to be concerned with shared user table
realizations.

zbigniew.braniecki wrote:

Brion: please, comment this bug. We're ready with two competing approaches here,
and I'm not sure which one do you prefer?

As I understand, all that should be necessary is to have a table prefix in
$wgSharedPrefix which will be used on the user table when $wgSharedDB
is in use.

I'm not really sure what all this other stuff is for.

gregory.szorc wrote:

Brion: You should be able to share any arbitrary table between wikis.
Shouldn't a wiki family be able to share the interwiki, math, and ip_blocks (and
possibly other) tables without having to modify the core function in
Database.php? On a personal note, I could really use this feature for Farmer
(http://www.mediawiki.org/wiki/User:IndyGreg/Farmer). Bottom line is the
current implementation restricts what 3rd party developers can accomplish. The
most recent patch fixes this.

zbigniew.braniecki wrote:

Brion: as Gregory stated, we came up to the point where we propose something
more flexible than what you say.

In our approach you can select which tables you want to share. There's no
difference for most users, because by default it only shares user table.

The real difference is for anyone who's willing to share other tables between
two mediawiki's or even store some tables in different location. Old approach
made it impossible, while the new one requires only to add a new
table_name=>db/prefix/tablename map to the array.

Do you find this an overkill and would prefer to get rid of this?

thomasV1 wrote:

using version 1.8.2.

In order to use $wgSharedDB with one single database and prefixes, I had to
change the following line in Database.php, in function tableName:

			if ( isset( $wgSharedDB ) && "{$this->mTablePrefix}user" == $name ) {
				$name = "`$wgSharedDB`.`$name`";

was changed to

			if ( isset( $wgSharedDB ) && "{$this->mTablePrefix}user" == $name ) {
				$name = "`$wgSharedDB`.user";

brion's answer to that is that he does not recommend using a prefix.
I would argue that you guys should not write code using a mTablePrefix variable,
if you assume that that variable is "". unless you have a sadistic personality.

lewis.jones wrote:

I am a novice interested party who is trying to share a user table, not between
wikis, but between mediawiki and another application.

Using your suggestions above, I have pointed mediawiki to the user table I want
to make the common one, but, because the username and password field names are
different and mediawiki requires additional mediawiki-specific fields in the
user table, it won't work.

From the point of view of development, it seems that to make the functionality
truly general, the patch will need to do several things:

1. allow administrators to map database_X.table_Y to database_W.table_Z, and
2. allow administrators to map from one field to another, and
3. automatically generate the mediawiki fields in the specified shared user

table (other than the ones already mapped, e.g. username and password), if that
is a user table from another application.

So, as part of the setup, then, you could specify the user table, and then be
allowed to map the appropriate fields, while setup goes on to add the rest of
the necessary fields to the user table.

I apologise for butting in where I can't really help at all, but it does seem
that people will increasingly want to integrate mediawiki with other
applications, and that the kind of thing I've outlined is what will be
necessary in order for that to happen.

lewis.jones wrote:

I am a novice interested party who is trying to share a user table, not between
wikis, but between mediawiki and another application.

Using your suggestions above, I have pointed mediawiki to the user table I want
to make the common one, but, because the username and password field names are
different and mediawiki requires additional mediawiki-specific fields in the
user table, it won't work.

From the point of view of development, it seems that to make the functionality
truly general, the patch will need to do several things:

1. allow administrators to map database_X.table_Y to database_W.table_Z, and
2. allow administrators to map from one field to another, and
3. automatically generate the mediawiki fields in the specified shared user

table (other than the ones already mapped, e.g. username and password), if that
is a user table from another application.

So, as part of the setup, then, you could specify the user table, and then be
allowed to map the appropriate fields, while setup goes on to add the rest of
the necessary fields to the user table.

I apologise for butting in where I can't really help at all, but it does seem
that people will increasingly want to integrate mediawiki with other
applications, and that the kind of thing I've outlined is what will be
necessary in order for that to happen.

robchur wrote:

(In reply to comment #53)

I am a novice interested party who is trying to share a user table, not between
wikis, but between mediawiki and another application.

Right, so stop here.

$wgSharedDB is for sharing databases between MediaWiki installations. To
instruct MediaWiki to authenticate against an external database, e.g. forum
packages, LDAP, etc. either write or find and install an appropriate
authentication plugin ("AuthPlugin"). You should be able to find quite a bit of
information on this via a normal web search.

lewis.jones wrote:

Thanks for that. Sorry to bother you guys.

I'll have a hunt around.

• Bug 9695 has been marked as a duplicate of this bug. ***

zbigniew.braniecki wrote:

Gregory's patch updated to tip

I've updated Gregory's patch to tip. It works very well.

Brion: can you support us with your point of view?
You stated your questions and I tried to answer them. How valuable you found
it?

Attached:

j wrote:

update to trunk to fix usage of $wgSharedDB.

This fixes a bug in trunk, for how $wgSharedDB is used (at least, by my understanding of a sane interaction with a prefix (or lack thereof)).

It looks like Gregory's patch is more comprehensive, but if you want to make a quick bug fix in the meantime, you can apply my patch. It is consistent with the recipe I describe here:

http://wiki.johnjosephbachir.org/Multiple_MediaWiki_instances_sharing_a_codebase_and_user_table

Attached:

I've done some testing:
http://tablename.dev.wiki-tools.com/

I've compared various new types of tableName methods:

• original is the current implementation.
• gregory is the suggested and tweaked patch here.
• rewrite is an old rewrite of tableName I had made. I never proposed this one anywhere because I hadn't tested it enough anywhere. But this test shows that it is working perfectly fine as expected (Well actually, I had to reverse a condition because I did something wrong in the original but it's fully functional now)
• And rewrite2 is my new proposal. It's basically a modified version of the rewrite made to support a map similar to gregory's.

The specifics of rewrite and primarily rewrite2 are:

• $wgSharedDB is still used, additionally there is a $wgSharedPrefix variable that can be set with the prefix to use for the shared database.
• $wgSharedTables is a array listing tables to be shared. If any table shows up in this list then the database used will be changed.
• $wgTableMap is a table mapping, for the most part it's simply equivalent to gregory's setup.
• Just for the hell of it I added a array cache. I can remove it if people don't like it, but there is little reason to go and run the same set of actions over and over when people ask for table names, so I just added it in.
• Just as a side effect there's a new format for input allowed. Normally we only allow "table" and as an override "database.table" to stop things from being done. There isn't much reason for it but you can use the format "database.table" and table will automatically get the current prefix. There isn't much use for it, but don't worry about anything breaking, currently if you try and do that you'll end up with "database.table" which breaks horribly.

One of the primary reasons I questioned it's compatibility was because I used a completely different method from the original. Instead of being ugly and testing things using the prefix over and over. I separate the name into it's database and table forms then take actions on the individual parts, and in the end combine them back together. A bit more elegant.

Oh... Right now there is one thing it's doing which I don't know if I should change:
When using the format "database.table" if table is set in $wgSharedTables then database will be overridden with the shared database. If you want, I can tweak it to honor the fact that the person asking for the table name explicitly gave a database name to use and expects it return that with the current prefix added.

Also, I honestly don't like the ability to change the actual name of the database. Basically redirecting revisions to page is possible, even by accident, and there is no valid reason to change the name of a table like that. Honestly, I'd like to change the way $wgTableMap works and define it as a database/prefix pair integrating it into the actual splitting and merging of the name.

The reason I'm using both a shared db config and a map is because I don't consider specifying individual locations for tables to be a very ideal way of configuring things when all you want is to share a set of tables with another wiki. But there is merit to allowing a different database/prefix for a certain table.

I'll try and have brion take a look at it when he gets back... If it's good I'll commit it to trunk, and if it works perfectly fine everywhere hopefully it can end up in 1.12 so wiki can make use of it (Wikia wanted to use the other version I committed to trunk, hate to have them add another hack to their setup).

Any notes or tweaks you want and I'll change the rewrite.

I'm pretty sure that these requirements should be sufficient for all sane uses:

• specify a single target database name + prefix for all shared tables
• specify the set of tables which are shared

Well... Actually, I can understand a sane use of a alternate table map:

$wgSharedDB set to a shared database for:

• users
• RegexBlock
• SpamRegex

And at the same time, they may want to share an interwiki table. However they want the interwiki table to be shared from their commons wiki rather than their shared database.

Or, there may be tri+ wiki sets where they only want a few tables shared, but those may be from one of the wiki, not others.
Kinda complicated chain to visualize. A wants table1 from B, B wants table2 from C, and C wants table3 from A.

Ok, I rewrote tableName and brion okayed a final version. This has been fixed as of r34353.

The new variables are $wgSharedPrefix and $wgSharedTables. The shared tables is only a list, not a map. Wanting to map tables rather than put them in a single shared database is a different bug. If there is a real good reason to have one a new bug should be opened to discuss it.