Portable Class Library

[ploeh]

Given the server-less nature of AtomEventStore, and given that it can use a normal file system as a storage mechanism, it seems that perhaps it would also be a good fit on mobile devices, as an alternative to a 'mobile' database implementation.

If that makes sense, perhaps AtomEventStore should be a Portable Class Library (PCL). It may simply be my naïvety that makes me consider this, but I understand that while PCL has been a difficult beast to tame previously, the technology should have matured in the last couple of years.

Writing this, I also don't know if it's possible to migrate AtomEventStore to a PCL, but it may be worth investigating.

If it can be done without introducing breaking changes, it sounds as a Pareto improvement. If it can be done, but only with breaking changes, we need to consider the options. One of those options may be to not make AtomEventStore a PCL at all.

[moodmosaic]

As far as I can tell, the System.Xml.XPath namespace is not available for Portable Class Library projects.

I just turned the AtomEventStore to a Portable Class Library with:

diff --git a/AtomEventStore/AtomEventStore.csproj b/AtomEventStore/AtomEventStore.csproj
index 15cebb1..fda1d95 100644
--- a/AtomEventStore/AtomEventStore.csproj
+++ b/AtomEventStore/AtomEventStore.csproj
@@ -11,6 +11,10 @@
     <AssemblyName>Grean.AtomEventStore</AssemblyName>
     <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
     <FileAlignment>512</FileAlignment>
+    <MinimumVisualStudioVersion>11.0</MinimumVisualStudioVersion>
+    <DefaultLanguage>en-US</DefaultLanguage>
+    <ProjectTypeGuids>{786C830F-07A1-408B-BD7F-6EE04809D6DB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
+    <TargetFrameworkProfile>Profile259</TargetFrameworkProfile>
   </PropertyGroup>
   <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
     <DebugSymbols>true</DebugSymbols>
@@ -42,15 +46,7 @@
     <RunCodeAnalysis>true</RunCodeAnalysis>
   </PropertyGroup>
   <ItemGroup>
-    <Reference Include="System" />
-    <Reference Include="System.Core" />
-    <Reference Include="System.Runtime.Serialization" />
-    <Reference Include="System.ServiceModel" />
-    <Reference Include="System.Xml.Linq" />
-    <Reference Include="System.Data.DataSetExtensions" />
-    <Reference Include="Microsoft.CSharp" />
-    <Reference Include="System.Data" />
-    <Reference Include="System.Xml" />
+    <!-- A reference to the entire .NET Framework is automatically included -->
   </ItemGroup>
   <ItemGroup>
     <Compile Include="AtomAuthor.cs" />
@@ -78,7 +74,7 @@
   <ItemGroup>
     <CodeAnalysisDictionary Include="CodeAnalysisDictionary.xml" />
   </ItemGroup>
-  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
+  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\Portable\$(TargetFrameworkVersion)\Microsoft.Portable.CSharp.targets" />
   <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
        Other similar extension points exist, see Microsoft.Common.targets.
   <Target Name="BeforeBuild">

The above diff shows the changes required to turn an existing .csproj file into a portable one. I found this by comparing a regular Class Library project with a Portable Class Library one.

As it looks like, the only way to make it happen is to use our own XPath query functions as we do in Qaiain.

[ploeh]

Funny that. Imagine the BCL design conversation:

"Let's make an intersection of all BCL APIs that are relevant on everything from big servers to small devices!"

"Great idea! What do we need, and what do we leave out?"

"Let's see... Hmm... System.Xml.XPath... "Provides a fast, read-only, in-memory representation of an XML document by using the XPath data model." Naah, we don't need that on small, memory-constrained devices!"

Boggles the mind...

[moodmosaic]

Yes, it does... I can't imagine why it was left out..!

FWIW, even if I choose the highest versions and Silvelight 5 it's still not there:

[ploeh]

My last comment was mostly a rant...

If the only barrier against turning AtomEventStore into a PCL is the lack of System.Xml.XPath, we should strongly consider refactoring its implementation to use XmlDocument instead.

The average size of each XML document handled by AtomEventStore depends on the configurable page size, but typically, when running with a page size of 25, the average document size I've seen has been approximately 31 kB, which, I assume, will also fit in memory on most smart phones, at least.

[moodmosaic]

Yep, and agreed on the ranting :) May I try to refactor the implementation and use XmlDocument instead?

[ploeh]

Go ahead :)

[moodmosaic]

As it looks like, targeting the PCL might be more than a refactoring process.

• The DirectoryInfo class is not available in PCL, which means the AtomEventsInFiles class would have to be removed – or use some custom file system abstraction.
• The XmlDocument class, defined in System.Xml (not in System.Xml.XPath), is not available in PCL which means we would have to define our own XPath query functions – or not use XPath at all.
• Since XmlTextWriter is not available, the CallBackXmlWriter helper class must derive from XmlWriter and it has to be turned into a Decorator and override all XmlWriter's abstract methods.

Given all the above, I think that targeting the PCL can result into at least one breaking change, less robust code (if we don't use XPath) and more code to maintain.

[ploeh]

OK. While the message is not what I have hoped, I really appreciate your efforts investigating this. Thank you.

Given that AtomEventStore is still young, with a very small user base, I don't think it worth pouring that kind of effort into it at this moment. Therefore, I hereby close the issue.

In the future, we can re-evaluate, if demand for a small device solution becomes noticeable.

[moodmosaic]

Yes, that's what I was thinking :)