SOP vNext initial compilation of features, pls. review/post your suggestions/feedback

Oct 2, 2012 at 7:45 AM

Here is the SOP roadmap which was compiled up to the release date of v4.5:

A. Small to Medium size projects:

 * Port SOP to mono c# in order to make it available to our Linux Open Source friends.

 * Create a LINQ provider for SOP to expand Query capabilities to support multi-Store LINQ statements.

 * Support multi-Reader, single-Writer Store. This is to further squeeze out any remaining "juice" in order to further increase scalability. A nice to have feature for optimization in support for very large number of concurrent Clients of an application using SOP as DB engine.

B. Big size projects:

 * Port SOP to Java to make this technology available to the Java developers. There are millions of embedded devices that do run Java written apps and the number increases by the day, having SOP available to these devices does offer some value. Although, maybe SOP port to Mono c# may somehow address this market segment, as a lot of these devices are running using some "variants" of Linux kernel, thus, having SOP in mono c# could alleviate this need, as mono .net runtime is/can be made available in Linux kernels.


This one requires deep SOP internal understandings, thus, 'may be a work item for somebody/team who has a pre-established SOP framework domain knowledge:

 * SOP server. Initial Server features thought about are mainly for enabling client/server transaction in SOP. Idea behind is to be able to use SOP in an efficient manner across Client and Server applications to increase performance and leverages multi-machine setup. Few of the ideas tossed around are:

    - create some form of two phase commit transaction solution. Client side SOP transaction will cache "locally" any transaction accessed/managed data, then on Commit, will submit "deltas" (new/updated/deleted) to the SOP server. Server side SOP transaction should be able to do some level of isolation hiding changes from unfinished transaction(s) being committed, and on commit, detect incompatible changes and rollback respective transaction(s) as necessary.

    - support very large "logical" Store by allowing configuration of SOP Store that are comprised of physical Stores residing across multiple machines. Objects submitted to this logical Store across client applications are load balanced amongst the actual Stores across machines.

    - design an API/interface for allowing application devs simple authorship of general level and application specific business rules that drive distribution/retrieval of objects. Create a default implementation containing some general level rules of Objects distribution.


Above items are preliminary, please feel free to suggest any ideas for SOP vNext...