what is the difference between plugin and library? - plugins

i wonder what the difference between a library and a plugin is?
if a component creates a database (maybe comes with a .sql file or creates through a method) could it still be a library or is it called a plugin or module?
cause i am creating a address book component and it provides methods to insert and read records in database. i don't know if i should put it in library folder or plugin folder.
please shed a light on this.
thanks

I vote for plugin.
A plugin extends the capabilities of a larger application. That sounds exactly like what your address book is doing.
A library is a collection of subroutines or classes used to develop software. I think any component that instantiates its own database falls outside the scope of a library.

This is a matter of opinion and of taste. Libraries tend to not do that much on their own but enable you ("the programmer") to do things. Though that could be said of many plugins as well...

Library: Is a collection of bunch of methods used to perform more number of task.
Plugin: Is a collection of few methods used to perform particular task.

I guess that would be more of a plugin. A library generally provides some pragmatic function or something. Like a way to access a service, or provide a function set, but it generally does not create a database of its own.

Plugin is your third party classes. Library is your own classes that you have implemented for your project.

Related

guidance on whether to use Annotation based spring boot graphql server

I am developing a new project with spring boot and graphql. I am confused on how to proceed because there are 2 ways to develop it, one is via the graphqls file and Annotation based approach. I prefer Annotation based approach but are they stable. exmaple : https://github.com/leangen/graphql-spqr.
I second AllirionX's answer and just want to add a few details.
Firstly, to answer your question: yes, SPQR has been pretty stable for quite a while now. Many teams are successfully using it in production. The only reason it is still in 0.X versions is the lack of documentation, but an occasional small breaking change in the API does occur.
Secondly, I'd also like to add that going code-first doesn't mean you can't also go contract-first. In fact, I'd argue you should still develop in that style. The only difference is that you get to write your contracts as Java interfaces instead of a new language.
As I highlight in SPQR's README:
Note that developing in the code-first style is still effectively
schema-first, the difference is that you develop your schema not in
yet another language, but in Java, with your IDE, the compiler and all
your tools helping you. Breaking changes to the schema mean the
compilation will fail. No need for linters or other fragile hacks.
So whether the API (as described by the interfaces) changes as the other code changes is entirely up to you. And if you need the SDL for any reason, it can always be generated from the executable schema or the introspection result.
I don't think there is a good or a bad answer to the "how to proceed" question.
There are two different approaches to build your graphql server (with graphl-java, graphql-java-tools, graphql-spqr), and each method has its advantages and inconvenients. All those library propose a springboot starter. Note that I never used graphql-spqr.
Schema first (with graphql-java or graphql-java-tools)
In this approach you first create a SDL file. The graphql library will parse it, and "all" you have to do is wire each graphql type to its data fetcher. The graphql-java-tools can even do the wiring for you.
Advantage
no need to enter into the detail of how the Graphql schema is built server side
you have a nice graphqls schema file that can be read and used by a client, easying the charge of building a graphql client
you actually define your api first (SDL schema): changing the implementation of the api will not require any change client side
Inconvenient
no compile-time check. If something is not wired properly, an exception will be thrown at runtime. But this can be negated by using graphql-java-codegen that will generate for you the java classes and interfaces for your graphql types, unions, queries, enums, etc.
if using graphql-java (no auto wiring), I felt I had to write long boring data fetchers. So I switched to graphql-java-tools.
Code first (with graphql-java or grapqhl-java-tools or graphql-spqr)
The graphql schema is built programmatically (through annotation with graphql-spqr or by building a GraphQLSchema object in graphql-java)
Advantage
compile-time check
no need to maintain both the SDL and the Domain class
Inconvenient
as your schema is generated from your code base, changing your code base will change the api, which might not be great for the clients depending on it.
This is my opinion on those different framework and I would be happy to be shown that I am in the wrong. The ultimate decision depends on your project: the size, if there is an existing code base, etc.

one for the experts: Pluggable gwt module & CompileModule class & XXXX.gwtar file?

Question for experts: Pluggable gwt module & CompileModule class & XXXX.gwtar file.
OK this one is for GWT experts!!
I have a GWT app that has widgets. We are shipping 5 widgets out of the box.
The widgets also depend on our API which act as simple DAO pojos
Now when this gets outs to customers. They have a requirement where they want to create their own widgets (as GWT modules) and use them inside our GWT app. Of course, to make things complicated, we cannot give them the source of our app or the API.
Now I know a more prevalent solution here is to have a JSNI API of some sort to have the widget and our app talk to each other, document it and have it rest in peace.
But we are also looking around to see if there are alternatives.
For example, looking at this CompileModule class
http://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/core/src/com/google/gwt/dev/CompileModule.java?r=10304
Can this be used to "mickey mouse" our sources.
It looks like this compiler will / could compile a module into a XXXX.gwtar file and in theory that might all customers would need to compile there custom module.
Any thoughts? Are we on to something here or is it dead end.
thanks
Ok looks like GWTAR is dead end for you. From the looks of it gwtar file is not enough to start the compilation, you will need to provide sources as well. Its sole purpose is to speed up compilation of really big applications, it will not be very helpful for your case.

Dynamic ORM - Perl

I am looking to upgrade an existing perl web-based application and wondering if there are any suggestions on how to solve a particular problem:
The application is used by several clients who each have a very customized dataset behind the scenes. There is very little overlap in the dataset between clients. However, they all load and use the same software. There are numerous configuration files that tell the software how to process this client and understand it's customized dataset.
In essence, there are common functions but different datasets that those functions work upon. I'm looking for a way to abstract the datasets into an ORM. However, most ORMs seem to expect a common dataset behind the scenes. I need to either load the ORM modules dynamically based on the client being used or dynamically create the ORM structure based on the same.
e.g.
The software provides View/Edit/Delete functionality but
Client A
Manages tables
Client B
Manages automobiles
The View function loads configuration files and has custom template files for each client that are relevant to the type of data they are managing.
Any suggestions?
Check out Jorge
See Rose::DB::Object (RDBO).
It support's loading the database structure at runtime by its Loader package. John Siracusa, the author of RDBO is always kindly responding to question in #rdbo on irc.perl.org or the mailing list.
It's also very fast (once loaded) and powerful. I can really recommend it if you have a DB application more complex than any example app.

Share some part of a static library

I'm pretty new to static libraries. I recently created one library because I have a lot of source code, and the updates of my projects ended as a nightmare.
So, this is a static library for iPhone.
My question is quite simple : I use this library for me and my company. But, how can I use a portion of it to make projects for my clients ? For example, I have a class which reads PDF or Photos, depending of the initialization parameters.
I don't want my client able to use the photo part, just by seeing the headers. How can i achieve that ? I thought to remove some parts of the headers i will give to my client, but i'm pretty sure there are better options.
Thanks
Presuming you are using objective C code, it will not be enough to just remove the headers since a smart client will be able to "ask" the code about its interface by using class-dump.
So if you want to be certain that the code is not available to your clients, you need to remove it completely from your static library.
Update:
CocoaReverseEngineering provides information about how to access the hidden information in frameworks and libraries. But you can also use it so you know what's possible and thus preventing it happening.

GWT Dynamic Module Loading

Is there a mechanism to dynamically load a GWT Module?
The idea is to create a pluggable GWT-based system: a core GWT module that dynamically loads another GWT module and a bus communication system to permit the communication through loaded modules.
Any help?
Possible duplicate of Web Application using OSGi and GWT
Also, see the information in this GWT User forum thread - http://groups.google.com/group/google-web-toolkit/msg/4a3f912cb89a7256
To summarize, its possible, but not recommended. Your requirement is orthogonal to GWT's philosophy and architecture. If you must, the GWT Exporter project is a useful starting point to enable communication between modules.
Code splitting does successfully handle the separated-loading issue -- but it does not address the separated-compilation issue.
Modular-interoperability with separated-compilation will never be the recommended default but GWT team should look into this in future.
If we are talking about a plug-in based architecture, different plug-in developer should develop their own UI and compile and give to the framework. Framework should dynamically load them.
I am still looking for and way to do it (do it better way).
You can use code splitting to dynamically loading the code when ever you want.
Have a look
http://code.google.com/webtoolkit/doc/latest/DevGuideCodeSplitting.html
See also comments at http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting, starting at 6th comment.