forums › forums › SQLyog › SQLyog: Bugs / Feature Requests › (Business) Application Integration With Sqlyog
- This topic is empty.
-
AuthorPosts
-
-
January 31, 2010 at 12:52 pm #11859jan marco alkemaMember
Hello Peter,
My idea is to make specific actions depending on the “content” of the specific tables. For example when I click right mouse in table “white_subscriber”, I get an extra option “Call Subscriber”. This option should call via the http://www.qutecom.org/ Voip-source (previously known as WengoPhone) the person in the white_subscriber table. See include screen dump as example template also.
Peter, May be you have some good advise for me—)
I don’t think my suggestion is the goal of SQLyog project, but is my approach of integration of an ('business') application with SQLyog a good one, or is there a better one?
Greeting Jan Marco
-
February 2, 2010 at 1:23 pm #30434peterlaursenParticipant
Well ..
The problem from our point of view is that there will be a single user/customer for every detailed implementation of this. You want to start a call from a phone no. column – somebody else may want to open a browser from a URL column or open a HEX-editor from a BLOB column etc. etc.
Also the 'content' is hard to identify in lots of cases. For instance I believe there is no international standard for phone numbers. How should SQLyog identify a string as a phone no? Is “99 1-4546-6789” a valid phone no. in Farawaystan?
For your particular 'project' we do not know either if this specific program has an API that makes it possible to control it from other programs or if it takes command line parameters such that the phone no. can be passed as a parameter to the program call. That would also be an requirement of course.
I think in conclusion that you should not expect us to try to implement this. It would not be very hard to add an item to the GRID-context menu calling an external program. Anybody with reasonable C-programming skills can do it (based on the COMMUNITY code that is freely available) if it is the only thing that is required.
-
February 5, 2010 at 8:27 am #30435jan marco alkemaMember
Hello Peter,
I have no request of changing the SQLyog program, only advise how to design with an other (business) program.
The telephone program is a good example to explain what my ideas are.
For example: You have a peer with 155 subscriber records. Nithin has a peer with 75 subscriber records and I have a peer with 90 subscriber records. How to do the database synchronization between the three peer?, without less publication of the subscriber records. Publication could encounter copy right violations.
Quote:The problem from our point of view is that there will be a single user/customer for every detailed implementation of this. You want to start a call from a phone no. column – somebody else may want to open a browser from a URL column or open a HEX-editor from a BLOB column etc. etc.If some one else or you change the value of a subscriber record. The old record will be placed in ‘subscriberarc’ table. Only a very short period there will be a problem with consistency, but there are semaphore and mutex routines to prevent this on 1 (virtual) PC.
Records have a ‘life cycle’, for instance a begin and end time. The VOIP call has a ‘life cycle’ (begin time stamp and end time stamp) also, you can determine which record is valid, the new record in subscriber table or the old one in ‘subscriberarc’ table. If a call begins a new record will be insert in a “voip” table. On this table the poll down menu will have relevant “options“, like ‘stop call’, ‘invite subscriber’, ‘resume call’, ‘transfer call’, etc. The integration with SQLyog is more intense than call an external program only.
Quote:Also the 'content' is hard to identify in lots of cases. For instance I believe there is no international standard for phone numbers. How should SQLyog identify a string as a phone no? Is “99 1-4546-6789” a valid phone no. in Farawaystan?The Phone numbers are used for searching the right entry in the table. You can see them as a “label” only. To call with the old “analog” telephone or to find a person. The peer IP is the key to communicate with other peers. If you start up the program (“SQLyog+wengo”) the public ip can be determinated very easily, if you are connected to internet. You search your own subscriber record in the subscriber table. In the pull down menu will be an option “set as default peer”. After that, your IP will be (automatically) synchronized with Nithin and my peer, by the synchronization of the subscriber table between the peers.
For database synchronization you should have the same table structure. I think of hashing the fields of a table. If you, Nithin and I have the same “table hash”, we could synchronize with each other.
Quote:For your particular 'project' we do not know either if this specific program has an API that makes it possible to control it from other programs or if it takes command line parameters such that the phone no. can be passed as a parameter to the program call. That would also be an requirement of course.Good one –)
Qutecom (Wengo) depends heavily on QT (I get it compiled, linked and executed with “qt-win-opensource-src-4.3.2” after a lot of study how to do it). I would get rid of QT as soon as possibly!
My strategy is to compile, link and test “qutecom-2-2-b816aa35e47cb”. This works at this moment. Now I am beginning to remove the (qutecom) dll’s, one after the other, by including the source in the project and remove the dll-dependency. After all dll’s are gone, I move the source (without QT sources) to the SQLyog source.
Quote:I think in conclusion that you should not expect us to try to implement this. It would not be very hard to add an item to the GRID-context menu calling an external program. Anybody with reasonable C-programming skills can do it (based on the COMMUNITY code that is freely available) if it is the only thing that is required.No, I think that integration should not be done by calling an extern program!
Conceptually an integration of SQLyog, Qutecom and Chrome (browser) would be nice.
1) SQLyog: The (table) interface to call, mail, order products, etc.
2) Qutecom: To communicate with other peers. “Some” peers are behind firewall. STUN concept, etc.
3) Chrome: Browsing the internet, very OS like solutions are programmed in Chrome. For Example: One program has different (sub) processes. The prio of threads are depending on the prio of the process (‘Real time’ VOIP calling to ‘batch’ database synchronization)
If these three programs are integrated, for example one good “worker thead pool concept” can be worked out, which is used by all ‘three’ program parts.
Greeting Jan Marco
-
February 5, 2010 at 10:04 am #30436DonQuichoteMember
The only thing SQLyog could do that would satisfy all customers or at least would not get in their way is to define some interface and let your application run as a plug-in. This is off course no small feature. Especially for blobs, this could be helpful. In fact, I already requested a comparable feature before. (see http://www.webyog.com/forums/index.php?showtopic=3211 )
Such a plug-in or external command interface could be quite “dumb” in the sense that it does not need to do any content parsing. You could leave that to the called plug-in or script. For instance, most formats start with some kind of header. The user can write a script that looks for supported headers and starts the appropriate application. For edit actions, the contents of the field could be written to a temp file and the temp file could be monitored for changes. For read-only cases, just start the application with the location of the temp file without monitoring.
If C scares you, you could try to adapt CrunchyFrog. It is an open source application written in Python with a plugin structure. It is not as feature-complete as SQLyog, but it is easily extended.
But I can understand why you would not implement all kinds of editors. SQLyog is like a swiss army knife. It is not suited for a specific business process, but a general database front-end. In my opinion, an extension possibility would fit the kind of application it is.
Alas I am not a C programmer…
-
March 21, 2010 at 11:12 am #30437jan marco alkemaMember
Hello DonQuichote,
After 4 days (hard) work, I have build the good environment to compile and link Openoffice successfully. Especially I am interested in Calc. Maybe SQLyog and Calc could be integrated in some way.
Quote:SQLyog is like a swiss army knife. It is not suited for a specific business process, but a general database front-end. In my opinion, an extension possibility would fit the kind of application it is.I think you have good advice for me: The intended purpose of SQLyog is an general front-end!
Only, I will trying to use the code for launch business programs/transactions for my own purpose also.
For example: I made a ProofOfConcept testtask scheduler with worker threads concepts. I use the concepts of http://en.wikipedia.org/wiki/Vertex_(graph_theory) and http://www.utm.edu/departments/math/graph/glossary.html to make a MySQL scheduler version. I use console (dox box) program for testing:
scheduler2 -findendpoints
scheduler2 -scheduleforward
scheduler2 -schedulebackward
scheduler2 -main
I use parts of http://www.codeproject.com/KB/system/RunUser.aspx also. I see another (newer) version on the internet: http://lab.mediaservice.net/code/RunAsUser.zip
A ‘testtask’, could be a backup, “set database engine in single user mode”, wget, etc. I need to work on the code, to implement more functionality. Maybe better putting the code in an standalone demon program.
Quote:But I can understand why you would not implement all kinds of editors.For example SQLYog and PowerEditor (NotePadPlus) uses both Scintilla source. Maybe I could integrated it in one program–)
Quote:If C scares you, you could try to adapt CrunchyFrog. It is an open source application written in Python with a plugin structure. It is not as feature-complete as SQLyog, but it is easily extended.MFC, Python, Perl and QT scares me. I love (‘Plain’) C in a Visual Studio (2005) environment.
Greetings Jan Marco
-
-
AuthorPosts
- You must be logged in to reply to this topic.