Hi everybody and thanks a lot for the input.
Tu sum up: it looks like there is enough interest on the topic
to justify further investigation.
In the meanwhile I comment the several posts to try to find a common
ground.
- Greg Freemyer
==========================================
>By "inter-engine communication" are you talking about something like
>Java's generic RMI interface that can span tiers, or something more
>specific to engines with well known services that is only used for
>intra-machine traffic?
I meant to talk about "something more specific to engines".
It would be interesting to work on something that can generalize the
idea.
...
>I'm still a newbie with Rails but it seems like any serious enterprise
>app will need to have an RMI like mechanism for the various tiers to
>talk together.
I agree. In my view the excellent Rails was born as a WebFramework, not
as an Enterprise Application Server, but has all the potential to become
one.
- David Corbin
==========================================
>I'd rather see a standardized interface where an engine can access
>authentication or authorization information.
If you drop the "rather", I fully agree ;-)
In fact my proposal is
1 - have a central entity to help discovering the needed service.
2 - to use the discovered service relying on standardized interface
and what you say is the second part of it.
> Can you give a concrete example of what you're thinking
> of with inter-engines communication?
Actually I could write a prototype, but before I want to collect ideas.
For the moment I send the following standard, very simplified,
"hub" code, just to avoid misunderstanding:
-- Client Engine
...
login = Engines.find_service(:login) # looks for a provider
...
login.validate(user, passwd) # uses standardized interface
... # for that kind of provider
-- Engines (framework side)
...
@services = {}
def Engines.start(engines) # (could be in the engines plugin)
engines.eaach{|engine| @services[engine.offered_service] = engines}
...
end
def Engines.find_service(desired_service); @services[desired_service]
end
...
-- Service Provider Engine
...
def offered_service; :login end # hub code
...
- Jay Levitt
==========================================
>I think that the proposal may be overly complex and genericized..
>defining
>a communications bus, service locator, etc. seems to be the opposite of
>"convention over configuration".
Not really.
1 - we are in Ruby: the expression "communications bus" is longer
than its implementation ;-)
2 - the complexity, if any, is on the framework side, not on the
Engine Client/Provider
> Better would be things like Bill Katz's recent post on defining a common
> DSL for authentication.
> The service registry becomes Usenet and the Rails wiki.
> The protocol becomes "authors talk to each other".
> The pointer is Google, and the naming convention is decided by
> the authors for any given service...
I am not familiar with Bill Katz's work, I'll check it out.
>From what you say it looks like something quite different from what I
suggest.
Having a registry on the net creates strong dependencies (no net, no
test)
"authors talk to each other" is always good, but far from maintainable.
>But then I can't really think of a whole lot of situations OTHER than
>authentication, version control, wiki, and maybe blogging where you'll
>likely have multiple engines implementing a common API but different
>underlying schemes.
Actually the whole topic started from your statement:
>> Another thing to think about: You want the engine to be easily
>> extensible without folks having to modify the actual engine files, or
>> cut-and-paste huge swaths of code.
Right!!!
Getting a pointer to the service you want to use (by name) and acquire
its
behaviours dynamically (dyn composition), is a way to address this.
The possibility to select between different implementation comes,
basically, as a free of charge side effect.
- Manuel Holtgrewe
=============================================
>Though I do not agree completely with DHH's opinion about high level
>components,
I keep hearing about it, but never read it. Could you give me a pointer?
> I think the project you described goes beyond the nice-
>and-easy things that Engines currently are and into the area of
>complex-hard-to-manage-and-Java-like things. Thus, the advantage of
>reuseability might come at a cost of too high complexity.
I agree with you: this has to be avoided at all costs!
A lot of people in the Rails world are refugees from
"complex-hard-to-manage-and-Java-like things" ;-)
There is a distinction to do though: is the complexity on the
framework or on its the users side?
Example: the fact that I need to type 15 time as much code to read a
file
in Java rather than in Ruby, doesn't mean that the Ruby interpreter
is simpler than the JVM. It means that it does more for me.
>I will certainly not try to stop you from doing it but in my opinion
>the mixin and override features of Ruby could do many things such a
>layer would do: Define some callback methods like ActiveRecord's
>callbacks and let users overwrite them in their current code.
Right. This could work and it is one of the topic I would like
to discuss in higher detail. In the article
http://cicio.org/articles/engines_isolation
I already tried to point out that in the engine community is
understimating the conflict risks (poor namespace usage).
The approach you suggest could be OK if applied in a consistent way.
>If you want to pursue your ideas further, you might want to look at
>existing dependency injection and inversion of control libraries as
>Needle [1]. It offers an interface for registering services.
I come from Spring, so this is a welcome hint. Thanks!
>While these systems can reduce the complexity of huge systems you
>have to get over an "entry complexity barrier" - lest you invest more
>time planning and implementing the required overhead such systems
>bring than you save compared with rewriting.
You are right. My aim is to use the space for improvement that
we have _without loss of simplicity_. If there is not such a space,
I rather drop the topic.
>I'll be interested to read more about your ideas, though.
And so do I about yours. You touched points I feel as very sensitive.
- Nathaniel Brown
===============================================
No too much to say here. I just fully agree :-)
- Mauro
--
Posted via http://www.ruby-forum.com/.
_______________________________________________
engine-users mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
