[Mono-list] A Plugin and WebService Issue

Dan dan@astusa.com
Mon, 24 May 2004 11:00:19 -0400


Or perhaps a custom build process that inspects the assembly after =
compile
checking for a specific set of members and displays error/warning =
messages
and even disposes of the assembly if need be.  Rules could be in an XML
file, whatever.

-Dan

-----Original Message-----
From: mono-list-admin@lists.ximian.com
[mailto:mono-list-admin@lists.ximian.com] On Behalf Of Mark Gimelfarb
Sent: Saturday, May 22, 2004 7:01 PM
To: mono-list@lists.ximian.com
Subject: RE: [Mono-list] A Plugin and WebService Issue

Since you generate the code from WSDL, why don't you preparse the WSDL =
doc
to see whether it contains the needed methods. WSDL is a subset of XML, =
so
parsing it shouldn't be hard, and if you know the (X)path to the element
containing the Method name that you are looking for, you can very easily
tell whether the code contains the needed methods even before =
compilation by
running an Xpath query on it. Mono does a terrific job in working with =
XML,
at least in my experience.

I do support Andrew though in that the approach he mentioned is probably
going to be preferred in .NET realm.

Regards,
        Mark.

Quoting Andrew Arnott <AndrewArnott@byu.edu>:

> >> I know that I can do this when the assembly is already compiled,=20
> >> but I'd like to do this BEFORE the assembly is compiled, so, if a=20
> >> method doesn't exists the compilation process should stop.
>=20
> What you are describing is what an interface does for you (or abstract =

> class in C#).  As far as I know, there's no way to make the C#=20
> compiler stop with an error when compiling valid code that is just=20
> missing a method you want, without using an interface.
>=20
> Also, if the code you are running and the code of the plugin will both =

> run on the same machine, I strongly suggest AGAINST SOAP.  SOAP is=20
> good for cross-platform communication, but it really slows you down=20
> when just communicating with other programs within the same machine=20
> because of all the XML generation and parsing with every method call=20
> and return.
>=20
> My suggestion would be use an interface and use compiled code.  .NET=20
> Remoting or Reflection, along with an interface, will do you the best, =

> I think.
>=20
> Regards
>=20
> Andrew Arnott
>=20
> -----Original Message-----
> From: mono-list-admin@lists.ximian.com=20
> [mailto:mono-list-admin@lists.ximian.com] On Behalf Of Pablo Fischer
> Sent: Saturday, May 22, 2004 11:10 AM
> To: mono-list@lists.ximian.com
> Subject: RE: [Mono-list] A Plugin and WebService Issue
>=20
> But that is after compiling the code, right?, with the MethodInfo,=20
> Get, Invoke methods.
>=20
> I know that I can do this when the assembly is already compiled, but=20
> I'd like to do this BEFORE the assembly is compiled, so, if a method=20
> doesn't exists the compilation process should stop.
>=20
> Pablo
> El s=E1b, 22-05-2004 a las 11:48, Mark Gimelfarb escribi=F3:
> > If I understand you correclty,
> > you can make use of the MethodInfo class to do method discovery.
> >=20
> > Regards,
> >         Mark.
> >=20
> > Quoting Pablo Fischer <pablo@pablo.com.mx>:
> >=20
> > > Ok ok, sorry ;-)
> > >=20
> > > If I want to create a plugin, I should generate the wsdl code of=20
> > > my webservice (SOAP) then compile it as a library.. this library=20
> > > is the plugin.
> > >=20
> > > What I'm looking for is that, when the user tries to make it=20
> > > library, the user should compile it with a resource or another=20
> > > library. The resource SHOULD look in the code before making it a
library.
> > >=20
> > > What SHOULD look in the WSDL code?, methods, so the resource=20
> > > should
> look
> > > if the WSDL code has a : Post method, a DeletePost, etc. if these=20
> > > methods are ok, then make it a library with some AssemblyInfo.
> > >=20
> > > Pablo
> > > El s=E1b, 22-05-2004 a las 11:08, Rob.Tillie@Student.tUL.EDU =
escribi=F3:
> > > > I don't fully understand you.
> > > > If you require that any plugin implements your interface ( which
> should
> > > have
> > > > those methods of you like Post etc.) then you're fine.
> > > > What else should you want then?
> > > >=20
> > > > Greetz,
> > > > -- Rob.
> > > >=20
> > > > -----Original Message-----
> > > > From: Pablo Fischer [mailto:pablo@pablo.com.mx]
> > > > Sent: Saturday, May 22, 2004 6:00 PM
> > > > To: mono-list@lists.ximian.com
> > > > Subject: RE: [Mono-list] A Plugin and WebService Issue
> > > >=20
> > > > Sure,
> > > >=20
> > > > I'd like to be sure that the plugin of the user has a 'Post'=20
> > > > method
> for
> > > > example, or a 'DeletePost', if all the 'rules' are ok the code=20
> > > > will
> be
> > > > compiled with an AssemblyInfo.
> > > >=20
> > > > I know that I can verify if the method exists invoking it and if =

> > > > I
> get
> > > > Null there's no method, but I'd like to do this also in the
> compilation
> > > > process.
> > > >=20
> > > > See ya!
> > > > El s=E1b, 22-05-2004 a las 00:22, Rob.Tillie@Student.tUL.EDU =
escribi=F3:
> > > > > Could you tell us why you want to check the code?
> > > > >=20
> > > > > Greetz,
> > > > > -- Rob.
> > > > >=20
> > > > > -----Original Message-----
> > > > > From: Pablo Fischer [mailto:pablo@pablo.com.mx]
> > > > > Sent: Thursday, May 20, 2004 5:04 PM
> > > > > To: mono-list@lists.ximian.com
> > > > > Subject: Re: [Mono-list] A Plugin and WebService Issue
> > > > >=20
> > > > > Thanks people!
> > > > >=20
> > > > > When I start writing my app (mbloggy) I was using Interfaces=20
> > > > > as
> plugins
> > > > > (xmlrpc plugins), then I started reading info about SOAP and=20
> > > > > I'm in
> > > love
> > > > > with it, the fact that SOAP supports any encoding makes me=20
> > > > > happy
> :-).
> > > > >=20
> > > > > What I was looking for is to do the same that "Plugins in =
Mono"
(M.
> > > > > Icaza) says :-).
> > > > >=20
> > > > > However, I'd like to ask something else: I want EVERY plugin=20
> > > > > be
> > > compiled
> > > > > like I want, yeah, when I compile the plugin (the .dll) I'd=20
> > > > > like to check the methods and validate the plugin, if the=20
> > > > > plugin is ok,
> compile
> > > > > it and add some Assembly Info (AssemblyInfo, right?), where=20
> > > > > should
> I
> > > > > look?, NUnit I think is to check compiled applications but I=20
> > > > > want
> to
> > > > > 'check' my code BEFORE being a .dll.
> > > > >=20
> > > > > Thanks!
> > > > > Pablo
> > > > > El jue, 20-05-2004 a las 05:38, RoBiK escribi=F3:
> > > > > > Hi,
> > > > > >=20
> > > > > > I would use this approach:
> > > > > >=20
> > > > > > 1) you must have a plug-in Interface defined, that each=20
> > > > > > plug-in
> must
> > > > > > implement
> > > > > > 2) when the application starts, use static
> > > > System.IO.Directory.GetFiles()
> > > > > > method to get the names of assemblies in the plug-in=20
> > > > > > directory
> > > > > > 3) for each plug-in-assembly file call static
> > > > > > System.Reflection.Assembly.LoadFrom() method to load the=20
> > > > > > assembly
> > > into
> > > > the
> > > > > > current AppDomain, then call the method
> > > > > > System.Reflection.Assembly.GetTypes() on the
> > > System.Reflection.Assembly
> > > > > > instance that you've got from the previous LoadFrom() method
> > > > > > 4) for each Type that you get from previous GetType() method =

> > > > > > use
> the
> > > > "is"
> > > > > > operator to check if the particular type implements the=20
> > > > > > plug-in
> > > > interface,
> > > > > > if it does, you have a type that implements your plug-in
> interface.=20
> > > > > > 5) call static Syste.Activator.CreateInstance() method with=20
> > > > > > the
> type
> > > > from
> > > > > > previous step as parameter. Cast the result to the
> plug-in-interface
> > > > type
> > > > > > and store it for example in an array for later use.
> > > > > > 6) now you have an array of plug-in instances and can call=20
> > > > > > the
> > > interface
> > > > > > methods on them
> > > > > >=20
> > > > > > This is just an example, there are several other approaches=20
> > > > > > which
> are
> > > > more
> > > > > > or less similar to this one... everything depends on the=20
> > > > > > needs of
> > > your
> > > > > > application.
> > > > > >=20
> > > > > > RoBiK
> > > > > >=20
> > > > > > Quoting Pablo Fischer <pablo@pablo.com.mx>:
> > > > > >=20
> > > > > > > Hi!
> > > > > > >
> > > > > > > I would like to have some comments and suggestions about a
> issue.
> > > > > > >
> > > > > > > I am working in a Blog Client (mbloggy) that will work=20
> > > > > > > ONLY in
> SOAP
> > > > (NO
> > > > > > > XMLRPC) for different CMS and Blogs (phpnuke, postnuke,=20
> > > > > > > jaws,
> etc,
> > > > etc).
> > > > > > > To work with all these blogs I'm  planning to use a =
'plugin'
> > > system,
> > > > > > > based in assemblies, for example:
> > > > > > >
> > > > > > > If a developer wants the plugin for a CMS (like drupal),=20
> > > > > > > he can
> > > save
> > > > his
> > > > > > > .dll plugin in ~./mbloggy/plugins and when mbloggy starts=20
> > > > > > > it
> will
> > > read
> > > > > > > default plugins (in /etc/mbloggy) and the user plugins.=20
> > > > > > > When
> > > mbloggy
> > > > > > > finds a new plugin it will be added to a 'drop down'=20
> > > > > > > (gtk#) so
> the
> > > > user
> > > > > > > can use it.
> > > > > > >
> > > > > > > My problem?, yes, I don't know which is the best option:
> > > > > > >
> > > > > > > a) Use .dll assemblies as plugins. But, how to connect to=20
> > > > > > > each
> > > plugin
> > > > > > > from the front end?, exists a data type that can 'clone'
> another
> > > > > > > object?, so I can do something like this:
> > > > > > >
> > > > > > > Wrapper wrap =3D new Wrapper(); =
wrap.Clone("assemblie.dll");=20
> > > > > > > wrap.Url =3D "http://www.foo.bar.com/foo.aspx?wsdl"
> > > > > > > wrap.DeletePost(3);
> > > > > > >
> > > > > > > So I can use the 'methods' of assemblie.dll in the wrap
> object?.
> > > > > > >
> > > > > > > b) Or use just one .dll and let the developers to =
'develop'
> just
> > > the
> > > > > > > WebService (server)?, So I can just work like this:
> > > > > > >
> > > > > > > Client c =3D new Client();
> > > > > > > c.Url =3D "http://www.foo.bar.com/foo.aspx?wsdl"
> > > > > > > c.DeletePost(3);
> > > > > > >
> > > > > > > Which is the best option? and where can I find more=20
> > > > > > > information
> for
> > > > the
> > > > > > > best option?.
> > > > > > >
> > > > > > > Thanks!
> > > > > > > Pablo
> > > > > > > --
> > > > > > > Pablo Fischer Sandoval (pablo [arroba/at] pablo.com.mx)
> > > > > > > Fingerprint:  5973 0F10 543F 54AE 1E41  EC81 0840 A10A=20
> > > > > > > 74A4
> E5C0
> > > > > > > http://www.pablo.com.mx
> > > > > > > http://www.debianmexico.org
> > > > > > >
> > > --
> > > Pablo Fischer Sandoval (pablo [arroba/at] pablo.com.mx)
> > > Fingerprint:  5973 0F10 543F 54AE 1E41  EC81 0840 A10A 74A4 E5C0=20
> > > http://www.pablo.com.mx http://www.debianmexico.org
> > >=20
> >=20
> >=20
> >=20
> > _______________________________________________
> > Mono-list maillist  -  Mono-list@lists.ximian.com=20
> > http://lists.ximian.com/mailman/listinfo/mono-list
> --
> Pablo Fischer Sandoval (pablo [arroba/at] pablo.com.mx)
> Fingerprint:  5973 0F10 543F 54AE 1E41  EC81 0840 A10A 74A4 E5C0=20
> http://www.pablo.com.mx http://www.debianmexico.org
>=20



_______________________________________________
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list