Reply to thread

Message

<blockquote data-quote="piranha" data-source="post: 295687" data-attributes="member: 15076">In all above aspects I agree with you. I think I misunderstood what you meant by &quot;client/server&quot; architecture.It is clear that now all plugins, and MP itself is limited in design to single seat and single db. Just moving to SQL of course doesn't solve the problem.What regular users mean by &quot;moving to SQL&quot; is actualy developers starting thinking about centralized storage and getting plugins ready in this direction.Some stuff like modifying similiar data at the same time is solved by SQL implementation itself, but definitely there is some &quot;homework&quot; to be done by the developer.By saying reinventing the wheel, I meant solution where you'd have a &quot;master instance&quot; of the plugin, which listens to &quot;client plugins&quot; and co-ordinates data storage via db3 or so. This is easily solved by transactional SQL. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />At my work, I do development with Oracle and M$ SQL, so I guess we speak the same language. Are you asking for proposals of actual implementation (because this will be dependent on each plugin), or you want to open discussion about &quot;core&quot; db handling by MP?The only thing that MP should provide, is common data provider which is independent from the plugin. It would/could take care of local db cache if necessary.&nbsp; So for example, on each MP client user needs to define which type of db to use, what's the IP of the server, username and password. Then each plugin would get it's own namespace (let's say each table for you would be prepended with mp_ (for moving pictures <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" /> ) and the actual table use/structure would depend on the developer of the plugin). Certain core tables (shared across all plugins) would help for sure. Tables like, users, settings, settings per user etc..I guess the most important part of the discussion is convincing developers that thinking outside single seat/user is a must. The other choice is to give them framework of db access, which will take the db development overhead away from them.</blockquote>

[QUOTE="piranha, post: 295687, member: 15076"] In all above aspects I agree with you. I think I misunderstood what you meant by "client/server" architecture. It is clear that now all plugins, and MP itself is limited in design to single seat and single db. Just moving to SQL of course doesn't solve the problem. What regular users mean by "moving to SQL" is actualy developers starting thinking about centralized storage and getting plugins ready in this direction. Some stuff like modifying similiar data at the same time is solved by SQL implementation itself, but definitely there is some "homework" to be done by the developer. By saying reinventing the wheel, I meant solution where you'd have a "master instance" of the plugin, which listens to "client plugins" and co-ordinates data storage via db3 or so. This is easily solved by transactional SQL. :) At my work, I do development with Oracle and M$ SQL, so I guess we speak the same language. Are you asking for proposals of actual implementation (because this will be dependent on each plugin), or you want to open discussion about "core" db handling by MP? The only thing that MP should provide, is common data provider which is independent from the plugin. It would/could take care of local db cache if necessary. So for example, on each MP client user needs to define which type of db to use, what's the IP of the server, username and password. Then each plugin would get it's own namespace (let's say each table for you would be prepended with mp_ (for moving pictures :) ) and the actual table use/structure would depend on the developer of the plugin). Certain core tables (shared across all plugins) would help for sure. Tables like, users, settings, settings per user etc.. I guess the most important part of the discussion is convincing developers that thinking outside single seat/user is a must. The other choice is to give them framework of db access, which will take the db development overhead away from them. [/QUOTE]

Verification