Vista Tutorial - ODBC/JDBC interface?

There has been mention that an ADO.NET interface to WinFS
could be in Beta 2.

Is there any thought to creating an ODBC or JDBC interface as well ?
--
Regards,
Rajesh

Hi Rajesh-

That is a good question. We currently have no plans to offer ODBC / JDBC
interfaces to WinFS stores. To be more concrete, the WinFS API will be
ADO.NET for Beta 2. This API we are building for WinFS will be built with
the *next* version of ADO.NET we are building. Specifically, we will be
heavily taking advantage of features being built into that version of
ADO.NET around Entity Data Modeling (mapping store-side schemas to
application layer objects).

Hope that answers your question!

--
Shan Sinha [MSFT]
shans@online.microsoft.com
This posting is provided "AS IS" with no warranties, and confers no rights

"Rajesh" <rchawla@nospam.nospam> wrote in message
news:A8EBAFEC-97D2-4786-9A71-3B5330655EE5@microsoft.com...
> There has been mention that an ADO.NET interface to WinFS
> could be in Beta 2.
>
> Is there any thought to creating an ODBC or JDBC interface as well ?
> --
> Regards,
> Rajesh
>

Shan,

Thanks for the quick and useful response.

So, if I understand you correctly the only way a
non-Microsoft client can access winfx is via
a SMB share.

Is this correct or am I missing something?

--
Regards,
Rajesh


"Shan Sinha [MSFT]" wrote:

> Hi Rajesh-
>
> That is a good question. We currently have no plans to offer ODBC / JDBC
> interfaces to WinFS stores. To be more concrete, the WinFS API will be
> ADO.NET for Beta 2. This API we are building for WinFS will be built with
> the *next* version of ADO.NET we are building. Specifically, we will be
> heavily taking advantage of features being built into that version of
> ADO.NET around Entity Data Modeling (mapping store-side schemas to
> application layer objects).
>
> Hope that answers your question!
>
> --
> Shan Sinha [MSFT]
> shans@online.microsoft.com
> This posting is provided "AS IS" with no warranties, and confers no rights
>
> "Rajesh" <rchawla@nospam.nospam> wrote in message
> news:A8EBAFEC-97D2-4786-9A71-3B5330655EE5@microsoft.com...
> > There has been mention that an ADO.NET interface to WinFS
> > could be in Beta 2.
> >
> > Is there any thought to creating an ODBC or JDBC interface as well ?
> > --
> > Regards,
> > Rajesh
> >
>
>
>

I see what you are getting at. Let me be a little more detailed with my
response. There are actually *two* APIs to interface with data stored in a
WinFS store.

a) ADO.NET vNext
b) Win32

I described to you why we are using ADO.NET vNext- we are taking advantage
of many of the features they are building around Entity Data Modeling.
These features include the ability to perform queries, joines and complex
"database-like" operations against data stored in the system (we call data
stored in WinFS, 'Items').

However, items can also be accessed through Win32. APIs like CreateFile,
FindFirst, FindNext all continue to work. For example, 'Items' that have a
File associated to them, calling CreateFile will return the file object
associated to the caller. However, the Win32 interfaces to items will not
provide the richer capabilities over the data that the ADO.NET interfaces
will allow.

So to answer your question- non-Microsoft clients can access the data stored
in a WinFS store in the following ways

a) Through SMB share but limited to the kinds of operations you can perform
with standard SMB and Win32 API
b) Create an ODBC / JDBC provider over SMB, though this would probably still
be limited to the same types of restrictions above (I bet that if you were
creative, you might still be able to do some interesting things to support
some of the additional capabilities over the data). Having said this.. this
probably would end up being tantamount to option 'c'....
c) implement a client-server like system where you place a server on the
Windows system that interfaces to WinFS data through ADO.NET interfaces and
essentially maps calls/responses from an ODBC / JDBC provider on the
non-windows client

Hope this answers your question!

--
Shan Sinha [MSFT]
shans@online.microsoft.com
This posting is provided "AS IS" with no warranties, and confers no rights




"rajesh" <rajesh@nospam.nospam> wrote in message
news:56DD3AAB-EF38-44D4-9D79-3E3DF953A919@microsoft.com...
> Shan,
>
> Thanks for the quick and useful response.
>
> So, if I understand you correctly the only way a
> non-Microsoft client can access winfx is via
> a SMB share.
>
> Is this correct or am I missing something?
>
> --
> Regards,
> Rajesh
>
>
> "Shan Sinha [MSFT]" wrote:
>
>> Hi Rajesh-
>>
>> That is a good question. We currently have no plans to offer ODBC / JDBC
>> interfaces to WinFS stores. To be more concrete, the WinFS API will be
>> ADO.NET for Beta 2. This API we are building for WinFS will be built
>> with
>> the *next* version of ADO.NET we are building. Specifically, we will be
>> heavily taking advantage of features being built into that version of
>> ADO.NET around Entity Data Modeling (mapping store-side schemas to
>> application layer objects).
>>
>> Hope that answers your question!
>>
>> --
>> Shan Sinha [MSFT]
>> shans@online.microsoft.com
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights
>>
>> "Rajesh" <rchawla@nospam.nospam> wrote in message
>> news:A8EBAFEC-97D2-4786-9A71-3B5330655EE5@microsoft.com...
>> > There has been mention that an ADO.NET interface to WinFS
>> > could be in Beta 2.
>> >
>> > Is there any thought to creating an ODBC or JDBC interface as well ?
>> > --
>> > Regards,
>> > Rajesh
>> >
>>
>>
>>

That does help.

Thanks!!

--
Regards,
Rajesh


"Shan Sinha [MSFT]" wrote:

> I see what you are getting at. Let me be a little more detailed with my
> response. There are actually *two* APIs to interface with data stored in a
> WinFS store.
>
> a) ADO.NET vNext
> b) Win32
>
> I described to you why we are using ADO.NET vNext- we are taking advantage
> of many of the features they are building around Entity Data Modeling.
> These features include the ability to perform queries, joines and complex
> "database-like" operations against data stored in the system (we call data
> stored in WinFS, 'Items').
>
> However, items can also be accessed through Win32. APIs like CreateFile,
> FindFirst, FindNext all continue to work. For example, 'Items' that have a
> File associated to them, calling CreateFile will return the file object
> associated to the caller. However, the Win32 interfaces to items will not
> provide the richer capabilities over the data that the ADO.NET interfaces
> will allow.
>
> So to answer your question- non-Microsoft clients can access the data stored
> in a WinFS store in the following ways
>
> a) Through SMB share but limited to the kinds of operations you can perform
> with standard SMB and Win32 API
> b) Create an ODBC / JDBC provider over SMB, though this would probably still
> be limited to the same types of restrictions above (I bet that if you were
> creative, you might still be able to do some interesting things to support
> some of the additional capabilities over the data). Having said this.. this
> probably would end up being tantamount to option 'c'....
> c) implement a client-server like system where you place a server on the
> Windows system that interfaces to WinFS data through ADO.NET interfaces and
> essentially maps calls/responses from an ODBC / JDBC provider on the
> non-windows client
>
> Hope this answers your question!
>
> --
> Shan Sinha [MSFT]
> shans@online.microsoft.com
> This posting is provided "AS IS" with no warranties, and confers no rights
>
>
>
>
> "rajesh" <rajesh@nospam.nospam> wrote in message
> news:56DD3AAB-EF38-44D4-9D79-3E3DF953A919@microsoft.com...
> > Shan,
> >
> > Thanks for the quick and useful response.
> >
> > So, if I understand you correctly the only way a
> > non-Microsoft client can access winfx is via
> > a SMB share.
> >
> > Is this correct or am I missing something?
> >
> > --
> > Regards,
> > Rajesh
> >
> >
> > "Shan Sinha [MSFT]" wrote:
> >
> >> Hi Rajesh-
> >>
> >> That is a good question. We currently have no plans to offer ODBC / JDBC
> >> interfaces to WinFS stores. To be more concrete, the WinFS API will be
> >> ADO.NET for Beta 2. This API we are building for WinFS will be built
> >> with
> >> the *next* version of ADO.NET we are building. Specifically, we will be
> >> heavily taking advantage of features being built into that version of
> >> ADO.NET around Entity Data Modeling (mapping store-side schemas to
> >> application layer objects).
> >>
> >> Hope that answers your question!
> >>
> >> --
> >> Shan Sinha [MSFT]
> >> shans@online.microsoft.com
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights
> >>
> >> "Rajesh" <rchawla@nospam.nospam> wrote in message
> >> news:A8EBAFEC-97D2-4786-9A71-3B5330655EE5@microsoft.com...
> >> > There has been mention that an ADO.NET interface to WinFS
> >> > could be in Beta 2.
> >> >
> >> > Is there any thought to creating an ODBC or JDBC interface as well ?
> >> > --
> >> > Regards,
> >> > Rajesh
> >> >
> >>
> >>
> >>
>
>
>

> To be more concrete, the WinFS API will be ADO.NET for Beta 2. This API
> we are building for WinFS will be built with the *next* version of ADO.NET
> we are building. Specifically, we will be heavily taking advantage of
> features being built into that version of ADO.NET around Entity Data
> Modeling (mapping store-side schemas to application layer objects).

does that mean that win fs beta 2/final api will have a lot of changes
comparing to beta 1 ?

will there be changes in namespaces only ? or something more ?

any chances for win fs beta 2 geing relased in 2006 q2 ?

ps. does ado.net vNext have anyting in common with linq ?

Hi Radoslaw

WinFS Beta 2 will have some substantial changes to the data model and
programming surface. Specifically, our entire containment / composition
model has been revised. We also have revised how links work. The bottom
line is that the Beta 1 schemas and applications will not be compatible with
Beta 2. On the API side, we are eliminating Opath and adopting the full
ADO.NET vNext surface.

The Beta 2 API will be very close to our final API. We do not paln for
major changes to occur between Beta 2 and RTM.

Beta 2 will also not be released in 2006 Q2. It will be released later this
year.

ADO.NET vNext has support for a part of the LINQ technologies called DLINQ.
ADO.NET vNext applications will be able to embed DLINQ in their applications
to interact with the data store tiers. By integrating with the ADO.NET API,
WinFS will inherit all of those capabilites.

Cheers!

--
Shan Sinha [MSFT]
shans@online.microsoft.com
This posting is provided "AS IS" with no warranties, and confers no rights

"radoslaw tereszczuk" <tereszczuk@it1.pl> wrote in message
news:OJCuC2VZGHA.5004@TK2MSFTNGP02.phx.gbl...
>> To be more concrete, the WinFS API will be ADO.NET for Beta 2. This API
>> we are building for WinFS will be built with the *next* version of
>> ADO.NET we are building. Specifically, we will be heavily taking
>> advantage of features being built into that version of ADO.NET around
>> Entity Data Modeling (mapping store-side schemas to application layer
>> objects).
>
> does that mean that win fs beta 2/final api will have a lot of changes
> comparing to beta 1 ?
>
> will there be changes in namespaces only ? or something more ?
>
> any chances for win fs beta 2 geing relased in 2006 q2 ?
>
> ps. does ado.net vNext have anyting in common with linq ?

Greetings,

WinFS seems to be a really interesting filesystem. I've searched to find more info on it. If you are also interested in this structure I suppose you give a look at this source
http://www.ntfs.com/