XFriendica - Federated Networking for XOOPS (Database Planning)
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: • friendica_addons • friendica_addons_functions • friendica_addons_modules • friendica_addons_protocols • friendica_addons_resources
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. • friendica_addons_functions
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. • friendica_networks • friendica_networks_paths
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.
Re: XFriendica - Federated Networking for XOOPS (Database Planning)
The database has been formalised, and is in it final planning phase, I have also built the raw classes for it with the XOOPS persistence modeler. Check out the Database, I have optimize the strip storage with the tabling so for XFriendica Alpha Database is now ready with classes for merger of the friendica code base, have moved the database around a bit so it is utilizing stripped storage that mysql performs better with http://code.google.com/p/chronolabs/d ... -%20Alpha%20-%20MySQL.htm
Now i am ready to start coding the structure of the software, there will be a couple more tables to add for the centralisation of core commands in the system for calling via plugins, adaptors, connectors and addons.. THis will be a commands that are used to map classes and functions so the software is script driven from a cache file built from the database for portability and so it floats there trans-buoyant.