Federated Networking for XOOPS. This is the Alpha's database planning. Based on Existing Protocol and Libraries for Friendica which is none modular as well as having a federation protocol i will be making one for XFriendica for a new Federation Protocol XIPS with XOOPS & XFriendica.
The following schemer is for the original friendica client for federated networking you can download this file which will show you the database as provided by the latest copy of friendica from their git hub: Friendica Latest - Schemer.htm - 553Kb.
Now with this schemer is for the XOOPS version of friendica client for federated networking I have removed all the systems like configuration and conflicting permissions systems and things like notifications as XOOPS has that all built in. When you download this file which will show you the database as it pretty much will be provided by the Alpha of xfriendica from Chronolabs: XFriendica - Alpha - MySQL.htm - 755Kb. You can also download the SQL dump, it is missing the inserted records but you will be able to look at the table structure if you run itXFriendica - Alpha - MySQL.sql - 46.7Kb
Anyway lets discuss the differences:
I sort of spent the last 4 hours planning the database, see I have an antispam honeypot called xortify.com that i am going to use for this unique process.
Remember XOOPS runs on a module system, so like the tag module there will be a plugin for each module to interact with the _item table through out the network making the mediums wider and more broad.
Let me a little explain what I have done here first with the addons:
See Schemer: friendica_addons
See I am adding a table group called networks, to replace the 2 fields in the admin settings for 'friends networks and email networks' this will also have some base level network one of which will point at xortify.com as a hidden system network - to download a series of 'plugins', 'connectors', 'adaptors' and 'addons' rather than distributing any but the core files to do this with the package. It can also in this database model download off other XFriendica sites api services the same series, they just wont be signed and you will be asked if you want to do this so you code base isn't made vunrable. But people can get the plugins, connectors and adaptors signed at xortify.com.
Each command will have an internal Token which is mapped in the _addons_functions table and executed with the instantiated class with checking anyway that the class has the method with method_exists() it will also use the magic functions __call($key, $value) and __callStatic($key, $value)
These three tables test the website if it has the correct settings, extensions and so on to execute the required, or optional inclusive part of the addon.. For example if a addon requires a particular module, then the addons_module table will be populated when the addon downloads, any protocols it uses that is like dfrn, or the protocol i will come up with for XFriendica called xips.. and the resources table checks for functions, classes and extensions that need to be or optional for features of the addon are installed.
These two tables are for storing domains, subdomains, and path of a network, it will be able to enquire on the site by the headers of the website, for information in it.. Both these tables link to one another.
This is the index retrieved from the network source of api functions and commands it has, which includes from both system network nodes as well as user nodes, their api details, this will mean people will be able to download plugins, adaptors and connectors off each other as well as the network node like xortify.com.
This is the keywords associated with each network, a linking table to friendica_keywords
The friendica_plugins folder works pretty much like the addons folder, with some sub tables for the mapping of the functions of the plugin and resources, modules or protocols either required or optional with the functions.
The profile table has changed, this is to support multifielding, so people can add in whatever field they want to the user profile and the code will create the field for it in the _profile_data table and map the field in _profile_field. Where fields can be grouped into categories and this will be all shared over the apis of XFriendica and when another site recieves fields it hasn't got on the profile there will be an option to automatically create it or ignore it in the config. _profile_keywords maps to the friendica_keywords table and allows for private and public keywords. and the _profile_visibility table is for control field visibility permissions to XOOPS Groups.
This is friendica_protocols which maps all the communication functions of protocols including the new one xips. The _protocol_functions maps the function to class and function and filename and _protocol_resources allows for testing of classes, functions and extensions for optional or requirements of a protocol ode.
See Schemer: friendica_guid
So for example friendica_guid has changed now there is two guid supported locale-guid for the local install guid and there is also a field for global-guid for example for an item, or request coming into the system, the locale-guid will be set based on the provided 'guid' by the resource as it's 'global-guid'. 'locale-guid' is what is refered to an item with-in the local node of an item on your instances of XFriendica, however any item/request generated by your local system will have in this table identical locale-guid & global-guid and provide these via push to the network.
Anyway, Your thoughts?