[Mono-dev] SxSVersion third stage: The vendor's problem

[Rodrigo Kumpera]

I think one aspect we should always keep in mind is make it easier for all
sides to work together.
We are not many and avoiding duplicate work is a good idea any time.

Atsushi, your email doesn't talk on this subject, but how this decision
affect the overall work
that will have to be done by the teams involved?

Cheers,
Rodrigo

On Sat, Jul 12, 2008 at 6:14 AM, Atsushi Eno <atsushi at ximian.com> wrote:

> (Forwarding to mono-devel-list as well.)
>
> If DBLinq project is to drop any other DB support than for SQL Server in
> System.Data.Linq.dll, I'm OK with that, since Mono community proved that
> it does
> not welcome improvements over compatibility stack anyways.
>
> Even if mono community started to want extensiblity, no worries. We
> could make
> some changes to add support for other databases, probably by adding
> Provider->Vendor resolution hack and/or adding external assemblies to
> support
> other DBs, when importing DBLinq tree to mono (mcs) build tree.
>
> I don't hesitate to fork some code in mono tree, as long as it could be
> almost
> harmlessly done. At least we always give our feedback on any desired
> changes,
> as we used to do :)
>
> Atsushi Eno
>
> This message is an official statement from the position and  does not
> represent
> the position of myself.
>
> Pascal Craponne wrote:
> > Hi Pablo,
> >
> > yes, that's the idea (I made minor changes this morning, I think they
> > are easy to understand), an IVendor implementation is identified by
> > its attribute.
> >
> > I placed all providers in x.Data.Linq.SqlClient namespace, exactly
> > like there are in the .NET specifications (and I just created now
> > Sql2000Provider and Sql2005Provider).
> > There are also other providers, such as MySqlProvider, OracleProvider,
> > and they are PUBLIC.
> > Now we have two options (not three) for MONO_STRICT:
> > 1. We want to support other databases and then we keep those providers
> > public and in System.Data.Linq assembly
> > 2. We don't want to keep those providers public and then we remove
> > support for other databases
> >
> > To me the choice is obvious. Make yours :)
> >
> > Pascal.
> >
> > On Sat, Jul 12, 2008 at 00:29, Pablo Iñigo Blasco <pibgeus at gmail.com
> > <mailto:pibgeus at gmail.com>> wrote:
> >
> >     Hi Pascal, thank for answering.
> >
> >     On Fri, Jul 11, 2008 at 20:02, Pascal Craponne <picrap at gmail.com
> >     <mailto:picrap at gmail.com>> wrote:
> >     "I don't like much your implementation of
> >     VendorFromProviderType(), but we may change it later (with
> >     reflection and assemblies scan), and please don't create any
> >     .Strict.cs file. If it is good for Mono, it is good for DbLinq :)"
> >
> >     I have seen your idea, it looks much better(and a strict.cs isn't
> >     needed) :-). Nonetheless I have a couple of questions:
> >     -Why isn't needed anoter assembly that contains providers types in
> >     strict mode?
> >     - How does the user of System.Data.Linq.dll do to specify wich
> >     vendor he want to use? As far as I understood your proposal is to
> >     mark with the providerattibutte both: user's "specific domain
> >     datacontext" and vendors implementations, isn't it?
> >     When both providerattributte's Type property match we would get
> >     the vendor to use, right?
> >
> >     Finally you said:
> >     "if we use reflection for method above, then there is no need to
> >     reference all drivers in a single assembly."
> >     Where are located those "providers classes" for the strict mode
> >     vendors?
> >     I think we need to have those providers types in an external
> >     assembly since they must be public (for the user's datacontext)
> >     and we shouldn't change System.Data.Linq API.
> >
> >     What haven't I understood?
> >
> >
> >     "Regarding Mono, you can place all vendors code in the
> >     System.Data.Linq.csproj."
> >     I did it. It was the main idea of the embeded approach.
> >
> >
> >     "I committed a version implementing VendorFromProviderType()
> >     (please rename this method, there's no verb in it)."
> >     Ok. I agree.
> >
> >     Regards.
> >
> >     PS:
> >     Excuse me about spelling mistakes, I am from a mobile phone.
> >
> >
> >
> >
> >
> > --
> > Pascal.
> >
> > jabber/gtalk: pascal at jabber.fr <mailto:pascal at jabber.fr>
> > msn: pascal at craponne.org <mailto:pascal at craponne.org>
> >
> > --~--~---------~--~----~------------~-------~--~----~
> > You received this message because you are subscribed to the Google
> > Groups "DbLinq" group.
> > To post to this group, send email to dblinq at googlegroups.com
> > To unsubscribe from this group, send email to
> > dblinq-unsubscribe at googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/dblinq?hl=en
> > -~----------~----~----~----~------~----~------~--~---
> >
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080712/d0c9708a/attachment.html