Skip to main content


Ideas for refactoring

@Friendica Developers @Friendica Support @Friendica Hackathon I just rewrote the part that is responsible for creating Friendica messages.

A last minute change was that this is now a class and the class functions are called statically. I'm using the class here mainly as some kind of namespace and to hide private functions that needn't to be exposed.

I'm planning to do the same for OStatus and Diaspora.

I like the idea of using classes as namespaces. I think we should have a look at the whole structure of the system.

We could do like this:

  • Files under /mod should never be included from other files
  • Most code should be removed from file
... mostra di più
Michael Vogel 1 anno fa
One addition:

We don't need to move out the whole code from /mod. Instead we should move all parts that could be usable in other places as well. For the file "mod/parse_url" this would mean that we split the parts for fetching the content from the different webpages from the parts that are responsible for displaying it.

Since only one file under /mod is included at a single time, we should name every class in these files "module". This would prevent us from misusing them :-) And this would avoid name conflicts. (When for example there is a "profile" class that is responsible for profile actions - and there would be a "profile" class that would be responsible for the module "profile")

The "module" should only have fixed public function names that are according to the current name scheme in the modules (like "content", "post", ...). In a later step we could call these classes directly from index.php instead of calling the procedural functions.

Fabio 1 anno fa
I like this. I think we can go a step furter and use php namespaces, PSR-0 file paths and autoloader.

A bullet list:
- use php namespace
- use folders (and namespaces) to clearly separe code
- use an autoloader to load classes: this will eliminate the need for "require/require_once/include" to files, and will load only classes really need for each run.
- create an interface for most of the core parts, and classes that implements them to do the work. I'm thinking about a ProtocolInterface which defines methods than protocols handlers classes must implement. Eg. 'DFRN' class that handle all bits to send and receive messages over dfrn, 'OStatus' for .. ostatus, and 'Diaspora' for.. ok, you got it..
I'm thinking about eg a "deliver()" method which every protocol class must implement, that accept a message and a contact and do it's work. (and with a system to register protocol classes in core, a plugin can define a new protocol that behave as natives)
- I would like to have classes that extracts from and insert data to database, to centralize SQL queries. I think... mostra di più

Michael Vogel 1 anno fa
I totally agree with the classes that should fetch data instead of decentralizd SQL queries.

With the "deliver" method I have to disagree. The three different protocols that we currently have implemented have a very different way of transmitting data.

Diaspora and Friendica are delivering comments via the thread starter. OStatus isn't doing this (pumpio as well), instead they are delivered like the other posts. But this is only the half of the truth. Every person that is mentioned (independently if the person is in our contact list or not) gets a notification via Salmon while the others are delivered via PubSubHubbub.

In Diaspora the big difference is if the post is public or private. For private posts you address the contact - but public posts are delivered to a different endpoint and only once per server.

You see, these three networks are behaving really different. Because of this I don't think that we can create such a "deliver" function.

Concerning these autoloaders, namespaces and so on: I never understood this whole stuff. I just had a look at... mostra di più

Rabuzarus 1 anno fa
according to autoloader and namespaces you may have a look at @beanow 's tree (have a look at the last commits)

I don't have knowledge about this because I started with php a year ago and my input is the actual friendica code but as far as I understand it, it is about to have more structured and reusable code.

Rabuzarus 1 anno fa
Just tried to get some information about this:
@Michael Vogel maybe the following videos are helpful

YouTube: PHP PSR-4 Autoloading Made Easy (Codecourse)

YouTube: PSR 4 Autoloading (Laracasts)

Maybe you can explain the benefits of use of autoloader and namespaces for friendica in a short simple way. The most important point I see is more structure but I think there is more than this.

Rabuzarus 1 anno fa
Have you looked at the commits of hubzillas dev branch the last two weeks? Interesting reorganisation happens there

Fabio 1 anno fa
I didn't look directly at the code, but I've read posts about that, and yes, it looks interesting

Tobias 1 anno fa da open socialverse
I don't want to spoil the fun (and I think the goal is right, eventhough I wont know how to do it) but could you 1st make vier working on the small screens ;-)

Michael Vogel 1 anno fa da Friendica for Android
Concerning "Vier" I thought everything should be okay now?

Rabuzarus 1 anno fa
Some things are left. Those of whom I know:
2.) pictures could break the mobile view because of fixed size (this is more possible if the thread level rises and the horizontal space is getting fewer)
3.) Post which includes events can break the mobile view.

Everyone can test it:
1.) Open friendica with Chrome/Chomium
2.) Open Chromes developer tool under other tools
3.) Press toogle mobile device in developer tools and select Apple iPhone 4 as device (after this you have to reload the page)
4.) visit your network page or other profile pages of friendica instances which are on friendica 3.5-dev

I think we should open a github issue which gathers all issues for vier mobile (doesn't github have such nice todo lists? )

According the issues I wrote above:
1.) I haven't looked into it until know (I need some time)
2.) This needs to be discussed max-width: 100% would solve it but there might be othe... mostra di più

Michael Vogel 1 anno fa
Concerning CSS I'm a rookie. I guess you can do this better than me.

Rabuzarus 1 anno fa
About this point I'm not really sure :-)

But it shows clearly what I want to say. For little CSS adjustments nobody have to be a professional coder. Everybody can experiment in his/her own browser.

What do you think what I'm doing :-D Playing with different css values in the developers tools of the browser and hoping that any value does it the right way ;-)

To look in this 3 issues is on my list. But there are so many things on this list. You all know it by your own :-)

Tobias 1 anno fa da open socialverse
What about refactor the API first? It should honor the ACL settings for postings/comments. I'm not shure how to formulate the issue for the üroblem, but I think it is worth a 3.4.3-3

Rabuzarus 1 anno fa
according to @Fabio comment above the api could benefit also from a refactor and cleaner code

Michael Vogel 1 anno fa
Comparing to other places the api is clean (leaving out the bugs).

Tobias 1 anno fa da open socialverse
@Michael Vogel not sure if this is because of the new DFRN code or because of the posting is going over three forums, but I see only 5 comments in this thread (but got notifications about mentions I do not see...) looking this thread up on I see 10 comments

@Rabuzarus the "you" is plural, not singular in this case as all three of you, whom I see on my node, have contributed over the Hackathon to make vier more responsive.

The privacy leaking via API is something though, which I think should be fixed ASAP and not as part of Friendica version 4.0

Fabio 1 anno fa
The most important thing is
more structured code
only really used classes are loaded per request

the two most important things are
more structured code and only really used classes are loaded per request

it's easier to use and update external libraries

the three!... mmh.. among the important things there are..

I'll rewrite the post...

Rabuzarus 1 anno fa
From my side it sounds OK. I think the most important point is to have a good doku on github and the friendica help pages so that others (me to) understand how it is working.

The biggest problem to for me is the question how to structure the whole (like I said above my horizon is the actual friendica code :-) but I'm willing to learn in small steps :-) )

PSR-0 or PSR-4? What are the advantages of each?

Fabio 1 anno fa
PSR-0 is deprecated

Fabio 1 anno fa
there are quite interesting reading in that site :-)