I’‘m kicking around an idea to contribute to wildfire. I haven’‘t had an “excuse” to learn Java yet and this seems like a good opportunity. My transports all have built-in web interfaces of their own and I was thinking about working on a way for the transports to basically announce to wildfire that "hey, I’‘ve got a web interface!" and then wildfire could list them amongst it’‘s own interface. Perhaps something via service discovery … like wildfire could look for a particular feature or whatever. The plugins seem extremely powerful so my guy feeling is that I could do this via a plugin. Might even write up a JEP for it if it comes out to be a really great feature. Certain… other… jabber server authors balked at the idea and never even responded to me when I suggested it. What do y’‘all think? (if you think it’‘s stupid, please say so ;D I’'d rather have negative comments than no comments)
While I’‘m at it, can anyone recommend some good books on Java? I’‘m not looking for a "here’‘s how to program" type of manual… I’‘m quite fluent in programming itself. I just basically need a language reference/"here’‘s how to do this in java" type of thing. I’‘ve been eyeing the in a nutshell book from o’'reilly. Any opinions on that?
Well, after I learned the very basics, I essentially learned to program in Java from the spec:
http://java.sun.com/j2se/1.5.0/docs/api/
There are some good tutorials at Sun’'s site, too; just poke around a little.
Timothy Collett
Hi Jadestorm,
when you say your transports have web interfaces do you mean administration interfaces or are you talking about something that a XMPP client might be able to use to send msgs via that transport?
Wildfire has a plugin concept which is quite well defined, which allows you to hook into the Wildfire administration web interface, as well intercept the message traffic. The API to the server is also pretty well commented. If this is suits you you could create a UI plugin that can be configured to open the web interface for you transport. i.e. in a frame.
I am wondering if your tranports fall in the realm of “external components” which Wildfire also supports.
In any case to implement service discovery for UI components would be an extra step. If you added an MBean (JMX) to your transports a generic UI plugin could easily be built to allow dynamic configuration of the tranports. You also have to be aware of security issues here.
No sure if that answers your questions but its food for thought! As for Java books I am a big fan of the head first series, the Java and Design Patterns books are excellant! But may be a bit too simplistic. As for how to do stuff - the Java Almanac (also online) has very useful examples.
Hope that helps,
Conor.
It maybe good to have a JEP which would allow through something like disco for a component to indicate that it has a web interface. I don’‘t think administration interfaces for XMPP servers or components has been formalized in any way but it would seem for me to be a good thing to be able to link from the Wildfire web interface to a component’'s web interface.
Also, this book is good:
Effective Jave Programming
Alex
In this particular case, the web interfaces for pyaim and pyicq “will do” a slew of things. At the moment they don’'t do a lot, but here are some of the things they do:
-
As a non-admin who is not registered with the transport, you would be able to register with the transport using the web interface … which would also handle auto-authing your entire AIM/ICQ roster so you don’'t have to click “Add/Auth” 8 bazillion times. =D
-
As a non-admin who is registered, you can see various information about your account. I’'m going to add various other functions in here… like perhaps the ability to change your password on the ICQ network and that kinda stuff.
-
As an admin, you can get various statistics and will be able to edit the config on the fly and perform various administrative actions.
Anyway, the transports themselves are external components, but they have this added built-in web interface. What I’'m aiming for is a way for -any- transport who wants to take advantage of it to be able to effectively tell Wildfire “I have a web interface at XXX url, please list it in your own interface”.
It sounds like the API for adding pieces to the web interface is pretty easy, and the service discovery part may or may not be easy. Note that the transports are written in Python. Also, ideally, I’‘d like other jabber servers to be able to potentially make use of the concept. I guess, long story short, I’‘m going for a more generic way for a component to indicate that it has it’‘s own built-in interface. I believe I can do this using Wildfire’'s plugin mechanisms. Then I might submit a JEP proposal that other servers could follow.
One perhaps crazy idea would be to automatically generate the web UI based on data forms and ad-hoc commands. So, query the external component for the configuration options and then automatically generate the UI. In the case of the wildfire admin console, that would be a web UI. It could just as easily be a desktop client.
This would certainly be a nice way to do the integration standards-wise. The difficult part would be building out the GUI rendering as well making a UI that is actually user-friendly.
Regards,
Matt
Yikes =D That’‘s a bit outside of my scope. I already have the look and feel of my web interface worked out, just would like a way of making it easier to find. Another side effect of this would be, ideally, that I could take my, we’‘ll say modified Psi client, and point it at the jid of a wildfire server and it could then provide me with the links to it’'s own web interface. http://whatever:9090/ for example.
Daniel,
Popping your own web UI into an iframe inside the Wildfire admin would work too.
-Matt
Hey Daniel,
Just to make things more “interesting” here are two possible solutions that can be used. These tools will let you provide a way to let “integrators” define the way they want your “pages” to look like and even the technology to use to render them (e.g. Flash, browser or desktop client).
XForms:[/b]
http://www.w3.org/MarkUp/Forms/
"What Are XForms?
Traditional HTML Web forms don’'t separate the purpose from the presentation of a form. XForms, in contrast, are comprised of separate sections that describe what the form does, and how the form looks. This allows for flexible presentation options, including classic XHTML forms, to be attached to an XML form definition."
XUL (XML UI Language):[/b]
http://luxor-xul.sourceforge.net/
Enjoy,
– Gato