ObjectDataMemberMapper extensibility

duke

I'm trying to write a fluent configuration thing for operations, but Photon insists on using its concrete implementation of ObjectDataMemberMapper.

I suggest inserting the following:

		private static IDictionary<Type, IObjectMapper> _mappers = new Dictionary<Type, IObjectMapper>();
	
    // Methods
    public static void RegisterTypeMapper<T>(IObjectMapper<T> converter)
    {
    	if(_mappers != null && !_mappers.ContainsKey(typeof(T)))
    		_mappers.Add(typeof(T), converter);
    }
    
    public static Dictionary<byte, object> GetValues(object source)
    {
    	var targetType = source.GetType();
    	
    	if(_mappers.ContainsKey(targetType))
    		return _mappers[targetType].GetValues(source);
    	else
    		return GetValues<DataMemberAttribute>(source);	
    }
    
    public static Dictionary<string, object> GetValuesByName(object source)
		{
			var targetType = source.GetType();
			
			if(_mappers.Containskey(targetType))
				return _mappers[targetType].GetValuesByName(source);
			else
				return GetValuesByName<DataMemberAttribute>(source);					
		}

IObjectMapper is just this:

public interface IObjectMapper<T>
{
	Dictionary<byte, object> GetValues(T source);
	Dictionary<byte, object> GetValuesByName(T source);
}

In general i'm not that impressed with the extensibility - you're calling concrete types all over the place, making replacing default implementations near impossible (and some are stuck in like settings delegate overrides), but this is a bit of a lengthier discussion.

dreamora

Indeed, Photon isn't that extendable but thats more cause the applications provided are sample applications to get started, to offer you a base.

Those applications aren't set in stone and present in precompiled form only so that you would be forced to use and extend them without being able to change anything.
As such it doesn't offer real hooks for extending it beside functionality related to operations and datatype serialization as it offers the source to the application itself to change it to whatever you want unlike other technologies where you only have access to a very limited part of the functionality and rely on extendability to create any custom capabilities at all.
Naturally you can also start with a complete barebone and build it all yourself from scratch on top of the highly performant and scaleable PhotonSocketServer base.

None the less I've brought up the point of 'Photon requires a extension / plugin mechanism' several times in the past and will remain and active advocate for such an aspect to be pushed, as the Photon cloud out of my view is missing 90%+ of its possibitilies due to 0 custom code and 0 persistence limitations

duke

I tried to do just that, implementing the interfaces to make my own AppBase, but there's a lot of inter-reliance on things with internal constructors, etc. InitRequest and response, for example. I'll take another look at it tomorrow.

Tobias

Thanks for nagging us about these topics. No joke!
It's good to read what could be useful and to get feedback on our stuff.

Dreamora is right: The Lite application and others are skeletons or framework. In worst case, these just work as showcase and you start your own stuff.

As Photon is not just a networking solution to send arbitrary data, it has some more fixed elements than those. Using a InitRequest is a must have, e.g.. Else the Photon core would not know which application to connect a peer to. Also, clients do these without a chance to skip them.
If you want some of the stuff Lite does but want to get rid of other parts, why not copy the project and source and then refactor it as needed?
Please let us know where you're stuck. The more concrete, the better we can adjust.
Note: I'm more at home on the client side, so I will just bring this up for discussion and can't give concrete answers right away.

Cloud and custom code: Pretty difficult. Each Photon process just runs one CLR and if the code is broken enough, it could bring down the runtime for all customers on that machine.
Of course we're looking into this and will offer something in the future. Right now, we're finalizing Photon 3. When that's done it's time for new stuff.

duke

So just to confirm - so i'm not barking up the wrong tree - if I adhere to the PhotonHostRuntimeInterfaces, I can effectively replace Photon.SocketServer?

dreamora

No, I don't think so.

The socket server is what makes Photon exist at all, its the native unmanaged application managing the socket communication in an efficient way, the stuff that actually starts up the .NET assemblies (Photon Applications) you write.
No Photon.SocketServer = no Photon

But you can replace and kick out all the Photon.Litexxx / LoadBalancing / MMO namespace related stuff if you don't want to use it and work straight with whats in the Photon Namespace itself