[FRAMEWORK] Notes from Skype Meeting - 23rd Oct 2015

[Sharan-F]

Hi Everyone

Yesterday we held a Skype call (Adrian, Ron, Taher and Myself)  to talk about the proposed Framework re-write. Please see below the main points from the meeting:

Meeting Discussions
We started by talking about our expectations. We then briefly discussed what a framework is as there are different interpretations. Our agreed definition was something around a basic central environment on top of which services, applications or even scripting could run.  

We also talked about the way that the current OFBiz framework has evolved and some of the resulting problems.  We have the opportunity to create something completely new and robust that resolves the issues we have encountered especially around dependencies.

We agreed that having a plan or roadmap would give us structure, visibility and would also keep us focussed on our end goal. We also decided that it would be good to start small and generic which would leave us open to able to  expand into other areas in the future.

What do we want to Achieve?
We had previously reviewed Adrian’s documentation  Initial Framework Vision Document and Initial Framework Design Document , and agreed during the meeting that this would be a good starting base for us. In this proposed subproject we would like to implement a framework that would initially comprise as follows:

   • Configuration.
   • Globalization (locale, time zone, currency).
   • Logging.
   • Security (authentication/authorization).
   • Actor Management (profiles, roles - required for security; Actors - people, external services) Think of UML Actor. Required to remove dependency on Party
   • Persistence (file system or database).
   • Lang package to provide classes that are fundamental to the framework
   • Services.
   • Runtime management

Initial Approach
At this stage we don’t currently have enough information to build our implementation roadmap so have agreed on an approach that will help provide that information.  The main steps are as follows:

   Expand and complete Framework Design Documentation 

   a. We need to describe and define what is meant by each of the 9 areas mentioned above. (what is it?, what does it do?).
   b. To do this we will write the API specification for each on the wiki
       (NOTE: Even though the API spec will be include Javadoc, we want to use the wiki rather than a repository at this stage as we want to validate and agree them before any coding starts :-)
   c. We will open the API specifications for review and comments from the community, and based on feedback, do any updates
   d. Once the API specifications are agreed, we will have more information about the work involved and should be able to put together an initial version of our implementation roadmap

Initial Deliverables
   • An API Specification for each of the 9 areas including Javadoc
   • An Implementation Roadmap

Initial Milestones
   • Completion of each API specification (includes feedback and community agreement) giving a total of 9

Outstanding  Actions
   • Find out what is involved in setting up a subproject repository and mailing list for the subproject within Apache  (Sharan)
   • Continue to complete API Spec documentation including Javadoc (Ron and Taher, with Adrian for review)
   • Review organisation and structure of other frameworks for ideas to incorporate (All)

I hope that I've captured the main points so Taher, Ron and Adrian, please feel free to add or update anything that I've missed or misinterpreted.

I also hope this update has been useful in giving everyone an idea of what we are initially planning to do. Please remember that if you are interested in helping us to complete the API specification documents or have any ideas that you think it would be good to incorporate then please include your comments in the various documents. As usual all contributions are welcome!

Thanks
Sharan

[Shi Jinghai-3]

Great!

-----邮件原件-----
发件人: Sharan-F [mailto:[hidden email]]
发送时间: 2015年10月24日 23:00
收件人: [hidden email]
主题: [FRAMEWORK] Notes from Skype Meeting - 23rd Oct 2015

Hi Everyone

Yesterday we held a Skype call (Adrian, Ron, Taher and Myself)  to talk
about the proposed Framework re-write. Please see below the main points from
the meeting:

*Meeting Discussions*
We started by talking about our expectations. We then briefly discussed what
a framework is as there are different interpretations. Our agreed definition
was something around a basic central environment on top of which services,
applications or even scripting could run.  

We also talked about the way that the current OFBiz framework has evolved
and some of the resulting problems.  We have the opportunity to create
something completely new and robust that resolves the issues we have
encountered especially around dependencies.

We agreed that having a plan or roadmap would give us structure, visibility
and would also keep us focussed on our end goal. We also decided that it
would be good to start small and generic which would leave us open to able
to  expand into other areas in the future.

*What do we want to Achieve?*
We had previously reviewed Adrian’s documentation   Initial Framework Vision
Document
<https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision>  
and  Initial Framework Design Document
<https://cwiki.apache.org/confluence/display/OFBIZ/A+New+Application+Framework+Design>  
, and agreed during the meeting that this would be a good starting base for
us. In this proposed subproject we would like to implement a framework that
would initially comprise as follows:

   • Configuration.
   • Globalization (locale, time zone, currency).
   • Logging.
   • Security (authentication/authorization).
   • Actor Management (profiles, roles - required for security; Actors -
people, external services) Think of UML Actor. Required to remove dependency
on Party
   • Persistence (file system or database).
   • Lang package to provide classes that are fundamental to the framework
   • Services.
   • Runtime management

*Initial Approach *
At this stage we don’t currently have enough information to build our
implementation roadmap so have agreed on an approach that will help provide
that information.  The main steps are as follows:
/*
   Expand and complete Framework Design Documentation* /

   a. We need to describe and define what is meant by each of the 9 areas
mentioned above. (what is it?, what does it do?).
   b. To do this we will write the API specification for each on the wiki
       (*NOTE*: Even though the API spec will be include Javadoc, we want to
use the wiki rather than a repository at this stage as we want to validate
and agree them before any coding starts :-)
   c. We will open the API specifications for review and comments from the
community, and based on feedback, do any updates
   d. Once the API specifications are agreed, we will have more information
about the work involved and should be able to put together an initial
version of our implementation roadmap

*Initial Deliverables *
   • An API Specification for each of the 9 areas including Javadoc
   • An Implementation Roadmap

*Initial Milestones*
   • Completion of each API specification (includes feedback and community
agreement) giving a total of 9

*Outstanding  Actions*
   • Find out what is involved in setting up a subproject repository and
mailing list for the subproject within Apache  (Sharan)
   • Continue to complete API Spec documentation including Javadoc (Ron and
Taher, with Adrian for review)
   • Review organisation and structure of other frameworks for ideas to
incorporate (All)

I hope that I've captured the main points so Taher, Ron and Adrian, please
feel free to add or update anything that I've missed or misinterpreted.

I also hope this update has been useful in giving everyone an idea of what
we are initially planning to do. Please remember that if you are interested
in helping us to complete the API specification documents or have any ideas
that you think it would be good to incorporate then please include your
comments in the various documents. As usual all contributions are welcome!

Thanks
Sharan








--
View this message in context: http://ofbiz.135035.n4.nabble.com/FRAMEWORK-Notes-from-Skype-Meeting-23rd-Oct-2015-tp4673855.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[Jacques Le Roux]

Thanks Sharan,

It's now totally clear to me :)

Thanks also to the other participants

Jacques

Le 25/10/2015 02:19, Shi Jinghai a écrit :

> Great!
>
> -----邮件原件-----
> 发件人: Sharan-F [mailto:[hidden email]]
> 发送时间: 2015年10月24日 23:00
> 收件人: [hidden email]
> 主题: [FRAMEWORK] Notes from Skype Meeting - 23rd Oct 2015
>
> Hi Everyone
>
> Yesterday we held a Skype call (Adrian, Ron, Taher and Myself)  to talk
> about the proposed Framework re-write. Please see below the main points from
> the meeting:
>
> *Meeting Discussions*
> We started by talking about our expectations. We then briefly discussed what
> a framework is as there are different interpretations. Our agreed definition
> was something around a basic central environment on top of which services,
> applications or even scripting could run.
>
> We also talked about the way that the current OFBiz framework has evolved
> and some of the resulting problems.  We have the opportunity to create
> something completely new and robust that resolves the issues we have
> encountered especially around dependencies.
>
> We agreed that having a plan or roadmap would give us structure, visibility
> and would also keep us focussed on our end goal. We also decided that it
> would be good to start small and generic which would leave us open to able
> to  expand into other areas in the future.
>
> *What do we want to Achieve?*
> We had previously reviewed Adrian’s documentation   Initial Framework Vision
> Document
> <https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision>
> and  Initial Framework Design Document
> <https://cwiki.apache.org/confluence/display/OFBIZ/A+New+Application+Framework+Design>
> , and agreed during the meeting that this would be a good starting base for
> us. In this proposed subproject we would like to implement a framework that
> would initially comprise as follows:
>
>     • Configuration.
>     • Globalization (locale, time zone, currency).
>     • Logging.
>     • Security (authentication/authorization).
>     • Actor Management (profiles, roles - required for security; Actors -
> people, external services) Think of UML Actor. Required to remove dependency
> on Party
>     • Persistence (file system or database).
>     • Lang package to provide classes that are fundamental to the framework
>     • Services.
>     • Runtime management
>
> *Initial Approach *
> At this stage we don’t currently have enough information to build our
> implementation roadmap so have agreed on an approach that will help provide
> that information.  The main steps are as follows:
> /*
>     Expand and complete Framework Design Documentation* /
>
>     a. We need to describe and define what is meant by each of the 9 areas
> mentioned above. (what is it?, what does it do?).
>     b. To do this we will write the API specification for each on the wiki
>         (*NOTE*: Even though the API spec will be include Javadoc, we want to
> use the wiki rather than a repository at this stage as we want to validate
> and agree them before any coding starts :-)
>     c. We will open the API specifications for review and comments from the
> community, and based on feedback, do any updates
>     d. Once the API specifications are agreed, we will have more information
> about the work involved and should be able to put together an initial
> version of our implementation roadmap
>
> *Initial Deliverables *
>     • An API Specification for each of the 9 areas including Javadoc
>     • An Implementation Roadmap
>
> *Initial Milestones*
>     • Completion of each API specification (includes feedback and community
> agreement) giving a total of 9
>
> *Outstanding  Actions*
>     • Find out what is involved in setting up a subproject repository and
> mailing list for the subproject within Apache  (Sharan)
>     • Continue to complete API Spec documentation including Javadoc (Ron and
> Taher, with Adrian for review)
>     • Review organisation and structure of other frameworks for ideas to
> incorporate (All)
>
> I hope that I've captured the main points so Taher, Ron and Adrian, please
> feel free to add or update anything that I've missed or misinterpreted.
>
> I also hope this update has been useful in giving everyone an idea of what
> we are initially planning to do. Please remember that if you are interested
> in helping us to complete the API specification documents or have any ideas
> that you think it would be good to incorporate then please include your
> comments in the various documents. As usual all contributions are welcome!
>
> Thanks
> Sharan
>
>
>
>
>
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/FRAMEWORK-Notes-from-Skype-Meeting-23rd-Oct-2015-tp4673855.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
>
>

[Nicolas Malin-2]

Nice,

I will really happy to help you, I try to follow the train ;) and first
step watch this presentation :)

Nicolas


Le 24/10/2015 16:59, Sharan-F a écrit :

> Hi Everyone
>
> Yesterday we held a Skype call (Adrian, Ron, Taher and Myself)  to talk
> about the proposed Framework re-write. Please see below the main points from
> the meeting:
>
> *Meeting Discussions*
> We started by talking about our expectations. We then briefly discussed what
> a framework is as there are different interpretations. Our agreed definition
> was something around a basic central environment on top of which services,
> applications or even scripting could run.
>
> We also talked about the way that the current OFBiz framework has evolved
> and some of the resulting problems.  We have the opportunity to create
> something completely new and robust that resolves the issues we have
> encountered especially around dependencies.
>
> We agreed that having a plan or roadmap would give us structure, visibility
> and would also keep us focussed on our end goal. We also decided that it
> would be good to start small and generic which would leave us open to able
> to  expand into other areas in the future.
>
> *What do we want to Achieve?*
> We had previously reviewed Adrian’s documentation   Initial Framework Vision
> Document
> <https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision>
> and  Initial Framework Design Document
> <https://cwiki.apache.org/confluence/display/OFBIZ/A+New+Application+Framework+Design>
> , and agreed during the meeting that this would be a good starting base for
> us. In this proposed subproject we would like to implement a framework that
> would initially comprise as follows:
>
>     • Configuration.
>     • Globalization (locale, time zone, currency).
>     • Logging.
>     • Security (authentication/authorization).
>     • Actor Management (profiles, roles - required for security; Actors -
> people, external services) Think of UML Actor. Required to remove dependency
> on Party
>     • Persistence (file system or database).
>     • Lang package to provide classes that are fundamental to the framework
>     • Services.
>     • Runtime management
>
> *Initial Approach *
> At this stage we don’t currently have enough information to build our
> implementation roadmap so have agreed on an approach that will help provide
> that information.  The main steps are as follows:
> /*
>     Expand and complete Framework Design Documentation* /
>
>     a. We need to describe and define what is meant by each of the 9 areas
> mentioned above. (what is it?, what does it do?).
>     b. To do this we will write the API specification for each on the wiki
>         (*NOTE*: Even though the API spec will be include Javadoc, we want to
> use the wiki rather than a repository at this stage as we want to validate
> and agree them before any coding starts :-)
>     c. We will open the API specifications for review and comments from the
> community, and based on feedback, do any updates
>     d. Once the API specifications are agreed, we will have more information
> about the work involved and should be able to put together an initial
> version of our implementation roadmap
>
> *Initial Deliverables *
>     • An API Specification for each of the 9 areas including Javadoc
>     • An Implementation Roadmap
>
> *Initial Milestones*
>     • Completion of each API specification (includes feedback and community
> agreement) giving a total of 9
>
> *Outstanding  Actions*
>     • Find out what is involved in setting up a subproject repository and
> mailing list for the subproject within Apache  (Sharan)
>     • Continue to complete API Spec documentation including Javadoc (Ron and
> Taher, with Adrian for review)
>     • Review organisation and structure of other frameworks for ideas to
> incorporate (All)
>
> I hope that I've captured the main points so Taher, Ron and Adrian, please
> feel free to add or update anything that I've missed or misinterpreted.
>
> I also hope this update has been useful in giving everyone an idea of what
> we are initially planning to do. Please remember that if you are interested
> in helping us to complete the API specification documents or have any ideas
> that you think it would be good to incorporate then please include your
> comments in the various documents. As usual all contributions are welcome!
>
> Thanks
> Sharan
>
>
>
>
>
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/FRAMEWORK-Notes-from-Skype-Meeting-23rd-Oct-2015-tp4673855.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.

[David E. Jones-2]

Some thoughts inline...

> On 24 Oct 2015, at 07:59, Sharan-F <[hidden email]> wrote:
>
> *What do we want to Achieve?*
> We had previously reviewed Adrian’s documentation   Initial Framework Vision
> Document
> <https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision>  
> and  Initial Framework Design Document
> <https://cwiki.apache.org/confluence/display/OFBIZ/A+New+Application+Framework+Design>  
> , and agreed during the meeting that this would be a good starting base for
> us. In this proposed subproject we would like to implement a framework that
> would initially comprise as follows:
>
>   • Configuration.
>   • Globalization (locale, time zone, currency).
>   • Logging.
>   • Security (authentication/authorization).
>   • Actor Management (profiles, roles - required for security; Actors -
> people, external services) Think of UML Actor. Required to remove dependency
> on Party

Is this just the user concept, or something bigger? In a framework, IMO, there is no need for the “Party” concept, but the user concept for authc/authz is critical.

Some side notes: Apache Shiro may be very useful in OFBiz for authentication and generic authorization, and I’d highly recommend looking at the artifact-aware authorization concept in Moqui for inheritable authz specific to screens, services, entities, etc. It is hugely useful for have this configurable external to the screens, services, etc themselves… much more flexible and simplifies code.

>   • Persistence (file system or database).

This seems a little broad, files are very different in nature from database records (assume relational DB referred to here, like the Entity Engine).

A file/resource interface can be backed by a filesystem, content repository, or even database tables that mimic the structure of a filesystem with DB records. For example see the ResourceFacade and ResourceReference in Moqui:

http://www.moqui.org/javadoc/org/moqui/context/ResourceFacade.html
http://www.moqui.org/javadoc/org/moqui/context/ResourceReference.html

Because a relational database is used so much a special interface to it is well worth the effort (like the Entity Engine). There are interfaces for this in Moqui, but no need to reference them here as the generic concept is the same (even if the API and design is very different).

One thing I would recommend for the new API is a find object instead of all the find methods on the delegator, ie something like:

http://www.moqui.org/javadoc/org/moqui/entity/EntityFind.html

It might be interesting to look at a generic interface for NoSQL databases like document, graph, etc DBs. However, the APIs for these are far less consistent than for relational databases so it is very difficult (impossible?) to design a generally useful interface, ends up being the least common denominator of the various underlying DBs.

>   • Lang package to provide classes that are fundamental to the framework

This is an area where OFBiz has a lot of room for improvement, and by improvement I mean getting rid of dozens of utility classes and using existing open source libraries instead.

>   • Services.
>   • Runtime management

What does Runtime management mean?

There are some key things missing for an adequate framework to replace the one in OFBiz, including:

- User Interface

How will screens and forms be implemented? How are they mapped to web requests? There is a lot of room for improvement in OFBiz here. Having to use a bunch of files and such for a single screen is a pain (controller request and view, screen, form, menu, tree, etc… often have 3-4 files open when working on a single screen). There is also no concept of a screen hierarchy (which is very useful) in OFBiz, just a flat list of supported requests.

- Integration (and non-UI web)

This might start with using something like Apache Camel, but also needs framework support for handling incoming integration web requests that may tie to entity or service operations, etc.

- Caching

Even if this is backed by something like Ehcache it may be nice to have a framework interface for using and managing caches.

- Transaction Management

Transactions are useful for more than just DB operations, but even with just DB stuff it is useful to make it easier to handle things like synchronizations to do stuff on commit or rollback. While sometimes useful in application code it is very useful for other tools (in Moqui this includes data feeds generated based on entity data changes, the write-through per-transaction cache, etc).

- Messages and Notifications

It is helpful to have a central place to handle messages (error and otherwise) that get passed up through the various levels of the framework, and to determine if something deeper down generated an error without using exceptions (which don’t fit the service model for logic very well, especially not remote services). Notifications are handy for pushing data to users or other applications, eventually through something like web sockets or other interfaces.

Another note is the original list is more conceptual than something that should be used to organize an API… for various reasons structuring an API this way would result in some weird structures.

I’ll finish with the most important point, IMO, for any framework design: a convenient single interface for the entire framework. This makes lifecycle management and API use so much easier, plus provides a single variable space (context) for all tools that is consistently available. This interface in Moqui is the ExecutionContext (always available in screens, services, scripts, etc as simple “ec”):

http://www.moqui.org/javadoc/org/moqui/context/ExecutionContext.html

To go along with that for management a primary factory is useful, for Moqui this is the ExecutionContextFactory:

http://www.moqui.org/javadoc/org/moqui/context/ExecutionContextFactory.html

If you want static initialization you can use the Java ServiceLoader, such as in:

https://github.com/moqui/moqui/blob/master/framework/src/api/java/org/moqui/Moqui.java

And a META-INF/services file like:

https://github.com/moqui/moqui/blob/master/framework/src/main/resources/META-INF/services/org.moqui.context.ExecutionContextFactory

-David

[Ron Wheeler]

My thinking about Actor is below:
Ron

On 29/10/2015 7:31 PM, David E. Jones wrote:

> Some thoughts inline...
>
>
>> On 24 Oct 2015, at 07:59, Sharan-F <[hidden email]> wrote:
>>
>> *What do we want to Achieve?*
>> We had previously reviewed Adrian’s documentation   Initial Framework Vision
>> Document
>> <https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision>
>> and  Initial Framework Design Document
>> <https://cwiki.apache.org/confluence/display/OFBIZ/A+New+Application+Framework+Design>
>> , and agreed during the meeting that this would be a good starting base for
>> us. In this proposed subproject we would like to implement a framework that
>> would initially comprise as follows:
>>
>>    • Configuration.
>>    • Globalization (locale, time zone, currency).
>>    • Logging.
>>    • Security (authentication/authorization).
>>    • Actor Management (profiles, roles - required for security; Actors -
>> people, external services) Think of UML Actor. Required to remove dependency
>> on Party
> Is this just the user concept, or something bigger? In a framework, IMO, there is no need for the “Party” concept, but the user concept for authc/authz is critical.

I am thinking that every application requires Actors.
Party is one kind of actor.
A user is an Actor.
A gayment gateway, an external SaaS application and an e-mail server are
also actors.
Actors have profiles and roles.
Profiles include all kinds of object from photos to birthdays to port
number to URLs.

If the framework offered Actors that supported profiles, this would
eliminate a lot of coding.

I am not just thinking of the framework as the base of OFBIZ ERP but
also as a general framework.

Think of the UML Actor. Actors appear in every Use Case.

>
> Some side notes: Apache Shiro may be very useful in OFBiz for authentication and generic authorization, and I’d highly recommend looking at the artifact-aware authorization concept in Moqui for inheritable authz specific to screens, services, entities, etc. It is hugely useful for have this configurable external to the screens, services, etc themselves… much more flexible and simplifies code.
>
>>    • Persistence (file system or database).
> This seems a little broad, files are very different in nature from database records (assume relational DB referred to here, like the Entity Engine).
>
> A file/resource interface can be backed by a filesystem, content repository, or even database tables that mimic the structure of a filesystem with DB records. For example see the ResourceFacade and ResourceReference in Moqui:
>
> http://www.moqui.org/javadoc/org/moqui/context/ResourceFacade.html
> http://www.moqui.org/javadoc/org/moqui/context/ResourceReference.html
>
> Because a relational database is used so much a special interface to it is well worth the effort (like the Entity Engine). There are interfaces for this in Moqui, but no need to reference them here as the generic concept is the same (even if the API and design is very different).
>
> One thing I would recommend for the new API is a find object instead of all the find methods on the delegator, ie something like:
>
> http://www.moqui.org/javadoc/org/moqui/entity/EntityFind.html
>
> It might be interesting to look at a generic interface for NoSQL databases like document, graph, etc DBs. However, the APIs for these are far less consistent than for relational databases so it is very difficult (impossible?) to design a generally useful interface, ends up being the least common denominator of the various underlying DBs.
>
>>    • Lang package to provide classes that are fundamental to the framework
> This is an area where OFBiz has a lot of room for improvement, and by improvement I mean getting rid of dozens of utility classes and using existing open source libraries instead.
>
>>    • Services.
>>    • Runtime management
> What does Runtime management mean?
>
> There are some key things missing for an adequate framework to replace the one in OFBiz, including:
>
> - User Interface
>
> How will screens and forms be implemented? How are they mapped to web requests? There is a lot of room for improvement in OFBiz here. Having to use a bunch of files and such for a single screen is a pain (controller request and view, screen, form, menu, tree, etc… often have 3-4 files open when working on a single screen). There is also no concept of a screen hierarchy (which is very useful) in OFBiz, just a flat list of supported requests.
>
> - Integration (and non-UI web)
>
> This might start with using something like Apache Camel, but also needs framework support for handling incoming integration web requests that may tie to entity or service operations, etc.
>
> - Caching
>
> Even if this is backed by something like Ehcache it may be nice to have a framework interface for using and managing caches.
>
> - Transaction Management
>
> Transactions are useful for more than just DB operations, but even with just DB stuff it is useful to make it easier to handle things like synchronizations to do stuff on commit or rollback. While sometimes useful in application code it is very useful for other tools (in Moqui this includes data feeds generated based on entity data changes, the write-through per-transaction cache, etc).
>
> - Messages and Notifications
>
> It is helpful to have a central place to handle messages (error and otherwise) that get passed up through the various levels of the framework, and to determine if something deeper down generated an error without using exceptions (which don’t fit the service model for logic very well, especially not remote services). Notifications are handy for pushing data to users or other applications, eventually through something like web sockets or other interfaces.
>
> Another note is the original list is more conceptual than something that should be used to organize an API… for various reasons structuring an API this way would result in some weird structures.
>
> I’ll finish with the most important point, IMO, for any framework design: a convenient single interface for the entire framework. This makes lifecycle management and API use so much easier, plus provides a single variable space (context) for all tools that is consistently available. This interface in Moqui is the ExecutionContext (always available in screens, services, scripts, etc as simple “ec”):
>
> http://www.moqui.org/javadoc/org/moqui/context/ExecutionContext.html
>
> To go along with that for management a primary factory is useful, for Moqui this is the ExecutionContextFactory:
>
> http://www.moqui.org/javadoc/org/moqui/context/ExecutionContextFactory.html
>
> If you want static initialization you can use the Java ServiceLoader, such as in:
>
> https://github.com/moqui/moqui/blob/master/framework/src/api/java/org/moqui/Moqui.java
>
> And a META-INF/services file like:
>
> https://github.com/moqui/moqui/blob/master/framework/src/main/resources/META-INF/services/org.moqui.context.ExecutionContextFactory
>
> -David
>
>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Sharan-F]

Hi Everyone

Thanks for all the feedback, comments and ideas we’ve had so far.  Based on that I think that we need to tighten up the scope so that we don’t try to do everything at once.

Thank you, Adrian for doing the diagram. I think this is a good way to see the big picture.

https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Sub+Project

I think it is very important to highlight that the scope of this current subproject is only the ‘foundation’ part of the framework.  If after the foundation has been implemented the community wants to continue then we can plan and implement the other pieces as the next steps.

Watching the video about API design, the key recommendation was that APIs should be simple, generic and agnostic. So what does that mean for us? I think it means we need to step back from ‘OFBiz’ during this particular analysis and design phase because we need to keep it simple. What I mean is that we need to imagine that we want to write these foundation APIs for a system that isn’t OFBiz. (Interesting thought – right?:-) So what could we put in place to make it generic enough to work with or without OFBiz?

So at this foundation level – I think it’s important that we don’t have any pre-conceived ideas about the scripting language, the business logic, the data model or even the applications that will use it because all of these are implemented in the levels above the foundation and not within the foundation itself.

I really think a minimalist approach with the foundation APIs is where we need to start, then once we have then, we can then continue on to build the implementation of our OFBiz specific requirements on top of it.

Thanks
Sharan

[Adrian Crum-3]

Thanks Sharan! The link you provided doesn't work. I think this is the
page you were referring to:

https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Project+for+the+Foundation+Sub+Component

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/31/2015 2:36 AM, Sharan-F wrote:

> Hi Everyone
>
> Thanks for all the feedback, comments and ideas we’ve had so far.  Based on
> that I think that we need to tighten up the scope so that we don’t try to do
> everything at once.
>
> Thank you, Adrian for doing the diagram. I think this is a good way to see
> the big picture.
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Sub+Project
>
> I think it is very important to highlight that the scope of this current
> subproject is *only the ‘foundation’ *part of the framework.  If after the
> foundation has been implemented the community wants to continue then we can
> plan and implement the other pieces as the next steps.
>
> Watching the video about API design, the key recommendation was that APIs
> should be simple, generic and agnostic. So what does that mean for us? I
> think it means we need to step back from ‘OFBiz’ during this particular
> analysis and design phase because we need to keep it simple. What I mean is
> that we need to imagine that we want to write these foundation APIs for a
> system that isn’t OFBiz. (Interesting thought – right?:-) So what could we
> put in place to make it generic enough to work with or without OFBiz?
>
> So at this foundation level – I think it’s important that we don’t have any
> pre-conceived ideas about the scripting language, the business logic, the
> data model or even the applications that will use it because all of these
> are implemented in the levels above the foundation and not within the
> foundation itself.
>
> I really think a minimalist approach with the foundation APIs is where we
> need to start, then once we have then, we can then continue on to build the
> implementation of our OFBiz specific requirements on top of it.
>
> Thanks
> Sharan
>
>
>
>
>
>
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/FRAMEWORK-Notes-from-Skype-Meeting-23rd-Oct-2015-tp4673855p4674035.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>