We had a discussion with @klinked some days ago and I shared with him that vision of an evolution of the OFN toward enabling people to create standalone websites “plugged” on a local public instance host by an OFN partner.
So to make it easy,here is my non-tech understanding, so basically we will have a public front end connected to the public OFN infrastructure that anyone can use, but the hubs who want or collection of hubs can create their own white label front-end / website / marketplace based on the public OFN infrastructure, so they don’t have to do their own deployment.
@klinked had some technical questions about how this will be done, so maybe you can share your view and ask questions here Kalin? Maybe @oeoeaio or @maikel or @RohanM will be able to answer you
This is connected to the discussion on micro-service architecture I guess… apparently this is not yet in this vision (or maybe the one mentioned by @enricostn in the discussion? the component/modules), but feel free to comment and share more precisely how you technically see those standalone website happening
@MyriamBoure thx for mentioning this
IMO this does not need to be related to microservices neither modularization. (although it would be easier to manage)
Btw the “embedded modules” and “The code” is something which I am not really sure what do you mean there how it would work.
My questions there were more functional however possibly affecting technical aspects.
For example if HubA wants a remote Shop fronted based on APIs we have a few options:
HubA has account in OFN central server
HubA does not have account in OFN central server but has API access to producers products and order mgmt ‘modules’
in case of 1) we can have also several options:
HubA is shown in central OFN
HubA is not shown in central OFN
HubA is not shown in central OFN but shown on the map
HubA is shown in central OFN but link redirects to remote site
but I guess we’ll ask them to pay for the service, right?
I’m not 100% sure but I guess that what we would need is to have a public API and sell the access to it. But they still have to manage their frontend development / deploying / maintainance, right?
Our idea for the first step is that HubA has an account with the central OFN server. There is a visible shop front. That shopfront loads products information as JSON from the server. In addition, HubA’s own website can use the same JSON API to load product information and display the shop, but in a different (whitelabled) way. The checkout and order confirmation has to be exposed through JSON APIs as well.
Hum… I don’t think the client we may have in France will be ok if their shops is also on the OFN… i think they would be ok if their hub is shown on the OFN map with a link that redirect to their shop in their own shopfront, but sincerly this is something that could be a “blocking point” as they want to master their image, and the shopfront on OFN is not the image they want to have (in terms of design, etc.) @maikel 100% they won’t agree with their shop being also in the OFN.
And I think this should be “customizable”, like a hub having his own website should decide if they want the hubs to be seen on the OFN map or not, the shopfront to be also in OFN (but them with the risk of unconsistency in their image) etc.
@enricostn I don’t have in mind at all making people pay to access the API… this is for me contrary to the effect we want to have, which support a super rich and diverse ecosystem to emerge around the OFN public infrastructures. For me the more open the API is, the more people will want to connect to it…
What we make people pay is the use of the OFN public infrastructure, like in UK they have this platform coop model, in France it’s more a wikipedia style, but it’s not the access to the API that people pay, they contribute to the cost of the public infrastructure they use, and that public infrastructure includes the API.
This is the way I see it as well. In a more federated approach each data owner should be able to decide where their data should be available. This includes not only the shops but the producers or other possible actors available in multiple systems.
@MyriamBoure@klinked this is what I meant, when I talk about charging a hub or a producer I always refer to let them contribute to the costs of maintaining OFN infrastructure.
Is anyone working on this currently? It looks like I’m going to be working on some Wordpress plugins as part of a funding application for a Hub I work with that will involve some sort of OFN shopfront type integration in an existing Wordpress site.
Cool. I’ve done some Wordpress development in the past. It uses an event-based system instead of MVC, with a weird “hook” system for inserting or modifying content/data when certain events are fired. The core API is very stable though, so usually any plugins that are built the right way are also very stable and don’t need updating when new releases come out.
