Hello,

Long overdue, I have finally committed the initial version of the odata package in the FPC repository.

This package provides the base for OData integration in your applications. OData is a standard adopted by the OASIS group: it describes data exchange through REST APIs. OData V4 and OData V2 are supported.

The workings of the OData integration are demonstrated in the conversion of the MS Office365 Unified REST API. (MS Graph).

This allows seamless integration of all Office365 components in your application.

Additionally, the (huge) Sharepoint Online REST API (which uses V2 of the OData protocol) has also been converted.

All this, with some sample programs and the conversion tool for OData metadata files, is committed in FPC's subversion, revision 34097.

Suggestions, testing: all welcome.

Enjoy,

Michael.

On Mon, Jul 11, 2016 at 10:50 AM, Michael Van Canneyt <

Is it worth its own repository, similar to googleapis?

thanks,
Dmitry

googleapis also does not have an own repository ?

Michael.

On Mon, Jul 11, 2016 at 1:05 PM, Michael Van Canneyt <

It's just taking more and more time to check out trunk.

thanks,
Dmitry

How often do you check out trunk ? I can't remember when I last did that.

I think I have explained my reasoning for including this in FPC SVN before: I consider these things as fundamental as the Win32 API or MacOS or libc headers. The world is more and more connected. More and more web APIs exist. That they happen to work over the net is irrelevant;

As such, I consider web APIs an essential part of the compiler (or indeed any) toolchain. In fact I think FPC is woefully behind in this department...

Michael.

PS. Maybe switching to git alone may make a checkout less painful, if we may believe some supporters... But that is the topic of a separate thread :-)

On Mon, Jul 11, 2016 at 2:32 PM, Michael Van Canneyt <

Then I have API design question.Is it possible not to bind web-apis to fcl-web package?

If my application is already using some other HTTP library (synapse or indy), I'd like to keep using it, even for the new API, rather than having code duplicating functionality (which would be fcl-web).

thanks,
Dmitry

Michael Van Canneyt wrote

Maybe switching to git alone may make a checkout less painful

I have no doubts. ;-)

Regards,
Graeme

2016-07-11 16:23 GMT-03:00 Graeme Geldenhuys
:

Regarding the checkout it would be slower than the svn checkout since git retrieves all the revision history.

In a project with such long history, it will take a while to complete the checkout.

In the other side, IMO git has advantages that outweight this drawback.

Luiz

Yes, absolutely.

If my application is already using some other HTTP library (synapse or indy), I'd like to keep using it, even for the new API, rather than having code duplicating functionality (which would be fcl-web).

Aha !!

I am VERY glad you asked this question.
I had the same consideration when creating it :-) :-)

In fact, the web-apis are bound only to fpwebclient and restbase units:

I put restbase.pp in fcl-web only because, well, a REST API _is_ web based. But I could put it in a separate package just as well :-)

fpwebclient contains only TFPAbstractWebclient.
This is an abstract class, for which I have 2 ready-made descendents:

- fphttpwebclient (which is in fcl-web and uses fphttpclient)
- synapsewebclient (it uses httpsend. I have the source in private, but I can publish it anywhere you want)
Both work equally well, I have used both in production.

The only reason I didn't yet implement a version for lnet or Indy, is because I didn't have the time...
But anyone looking at the code for synapse or fphttpwebclient can make a descendant in less than half an hour.

We could put the source code for all non-strict-FPC descendants in the fpcprojects repository, or I could publish them on my github page. (Which is very empty at the moment)

Michael.

On Mon, Jul 11, 2016 at 5:12 PM, Michael Van Canneyt <

Got it. Thank you for clarification.

before: I consider these things as fundamental as the Win32 API or MacOS or libc headers. The world is more and more connected. More and more web APIs exist. That they happen to work over the net is irrelevant;

As such, I consider web APIs an essential part of the compiler (or indeed

any) toolchain. In fact I think FPC is woefully behind in this department...

I personally(!) would prefer this and quite some other packages of the packages dir to be in an official repo for fppkg. Especially the googleapis package (and I'd guess this one as well) does really add quite a bit of compilation time on my older machines...

Regards,
Sven

Luiz Americo Pereira Camara wrote

Regarding the checkout it would be slower than the svn checkout since git retrieves all the revision history.

Only if you want the full history - you have a choice. For example...

git clone --depth 8 https://github.com/graemeg/freepascal fpc-3.1.1

...will only have a history of 8 commits per branch after the initial checkout. This took 18 seconds on my system. I’m based in the UK, and I gather Github is in the USA somewhere.

That time is just the initial checkout. After that you do a ‘git pull’ and it will take 1-3 seconds to update with the latest code changes. The actual download size is minimal, as git only downloads compressed commit deltas after the initial clone.

In the other side, IMO git has advantages that outweight this drawback.

+1000
But that’s not for this discussion.

Regards,
Graeme

Michael Van Canneyt wrote

PS. Maybe switching to git alone may make a checkout less painful, if we may believe some supporters... But that is the topic of a separate thread :-)

... and a separate list. Everyone, please continue all git-related remarks/discussion on the fpc-other list.

Thanks,

Jonas
FPC mailing lists admin

In our previous episode, Michael Van Canneyt said:

PS. Maybe switching to git alone may make a checkout less painful, if we may believe some supporters... But that is the topic of a separate thread :-)

Wrong problem, better eliminate the need for repeated checkouts rather than optimize them.

The core thing to do would be to adopt a mechanism like configure where build and source directories are strictly separated. This would avoid 99% of the problems of having to do a fresh checkout for automated builds, and also be a great asset in crossbuilding.

What is wrong with

svn status | grep '^?' | awk '{ print $2 }' | xargs rm -rf

This ensures a pristine copy ?

Or you can do an

svn export

from an already checked-out copy. This leaves you with a pristine copy too.

Michael.

In our previous episode, Michael Van Canneyt said:

C:\repo\fpc>svn status | grep '^?' | awk '{ print $2 }' | xargs rm -rf 'awk' is not recognized as an internal or external command, operable program or batch file.

And even besides the multiplatform angle, a simple

rm -rf buildwin32

would only delete one targets build files, and the source dir could be on a different fs etc.

And there is not really a big disadvantage to having builddirs. (note I only meant meant the practice of having build dirs as option, not configure or anything else related to configure. A BUILD=../build to current make so to say)

That's what I did when I still had a slow link. Still related to checkout size though.

I really don't see what this solves since all resulting files are put in units/$CPU-$OS anyway ?

Michael.