Re: Haxe Digest, Vol 52, Issue 8

classic Classic list List threaded Threaded
3 messages Options
obi
Reply | Threaded
Open this post in threaded view
|

Re: Haxe Digest, Vol 52, Issue 8

obi
Hey,
Cool work indeed on the API.

There are three things which I came across while thinking on the topic:
1) Will the API evolve somehow in future? What about its versions &
usage in different projects in time?
2) Today its more & more used technique to access remote file systems
(like through ftp for example), where new additions are SVN, GIT &
etc... Do you plan to make the api supporting any other protocols as
well?
3) What I do in my daily job is creating large amount of service
applications serving different purposes, to which I'm using one
similar apiLIB made for my own needs:
http://github.com/outbounder/org.abn.haxe. So what do you think will
be the most rational & simple way of integrating those two apis in the
sake of software products development? Keep in mind that eventually
everything changes, as well as the APIs in place, but old projects
sometimes need to be maintained and/or even improved  :)

Kind regards,
Boris


> Date: Tue, 2 Feb 2010 15:53:26 +0000
> From: Juan Delgado <[hidden email]>
> Subject: Re: [haXe] XAPI (Ximple API)
> To: The haXe compiler list <[hidden email]>
> Message-ID:
>        <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi!
>
> 2010/2/2 Heinz Hölzer <[hidden email]>:
>> sounds great,
>>
>> is the filter function executed on folders and files?
>
> Yes. The filter function receives a call per item (either file or
> folder) and has to return a boolean to approve (true) or deny (false).
> Both search and copy default to a filter that returns true (everything
> copied, everything returned in the search).
>
> BTW, just committed the raw source code (no docs, test or samples yet)
> to github:
>
> http://github.com/zarate/xapi
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe Digest, Vol 52, Issue 8

Shelby Moore
URLs for namespace (truncated for terse coding, similar to how now package
directories up to the hierarchy of avoiding collisions), then more
granular APIs, so we don't upgrade (re-use) the namespace, we just freeze
it (except for bug fixes) and make another name for new version:

http://lists.motion-twin.com/pipermail/haxe/2010-February/033420.html

I don't want to take time to explain in detail.  I will post to mailing
list when I have it working.


> Hey,
> Cool work indeed on the API.
>
> There are three things which I came across while thinking on the topic:
> 1) Will the API evolve somehow in future? What about its versions &
> usage in different projects in time?
> 2) Today its more & more used technique to access remote file systems
> (like through ftp for example), where new additions are SVN, GIT &
> etc... Do you plan to make the api supporting any other protocols as
> well?
> 3) What I do in my daily job is creating large amount of service
> applications serving different purposes, to which I'm using one
> similar apiLIB made for my own needs:
> http://github.com/outbounder/org.abn.haxe. So what do you think will
> be the most rational & simple way of integrating those two apis in the
> sake of software products development? Keep in mind that eventually
> everything changes, as well as the APIs in place, but old projects
> sometimes need to be maintained and/or even improved  :)

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe Digest, Vol 52, Issue 8

Juan Delgado
In reply to this post by obi
Hi there,

>
> There are three things which I came across while thinking on the topic:
> 1) Will the API evolve somehow in future? What about its versions &
> usage in different projects in time?

Well, can't say it's not going to evolve, but at the same time I'd
like to keep it stable? I plan to tag (or whatever that is in Git,
don't know yet!) the master once  I add the documentation to the code
and pretty much that's it.

Then tag whenever we feel like there's an important milestone, really.
Haven't given it too much thought, to be honest.

> 2) Today its more & more used technique to access remote file systems
> (like through ftp for example), where new additions are SVN, GIT &
> etc... Do you plan to make the api supporting any other protocols as
> well?


No, that wasn't the idea. Shelby brought it up as well and I think
it's awesome, but to me it looks way beyond the scope of Xapi.

> 3) What I do in my daily job is creating large amount of service
> applications serving different purposes, to which I'm using one
> similar apiLIB made for my own needs:
> http://github.com/outbounder/org.abn.haxe. So what do you think will
> be the most rational & simple way of integrating those two apis in the
> sake of software products development? Keep in mind that eventually
> everything changes, as well as the APIs in place, but old projects
> sometimes need to be maintained and/or even improved  :)
>

Well, we could look where they kind of overlap and try to merge them
where necessary.

Having said that, I don't think an API can serve ALL projects. For
example, Xapi is no way better than the official Std API, just servers
a different purpose (simplicity) whereas with the official API you can
do much more (at the "cost" of a higher learning curve).

What I mean is, and coming back to the point of having an API to
handle different file systems (local, ftp, etc), that I'd personally
have several smaller projects that relate to each other.

We could develop such library to handle several file systems and make
xapi internally use it to provide local file access (which is more
than enough for quite a few apps). But IMHO I'd keep those 2 libraries
separated.

What you think?

J

> Kind regards,
> Boris
>
>
>> Date: Tue, 2 Feb 2010 15:53:26 +0000
>> From: Juan Delgado <[hidden email]>
>> Subject: Re: [haXe] XAPI (Ximple API)
>> To: The haXe compiler list <[hidden email]>
>> Message-ID:
>>        <[hidden email]>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hi!
>>
>> 2010/2/2 Heinz Hölzer <[hidden email]>:
>>> sounds great,
>>>
>>> is the filter function executed on folders and files?
>>
>> Yes. The filter function receives a call per item (either file or
>> folder) and has to return a boolean to approve (true) or deny (false).
>> Both search and copy default to a filter that returns true (everything
>> copied, everything returned in the search).
>>
>> BTW, just committed the raw source code (no docs, test or samples yet)
>> to github:
>>
>> http://github.com/zarate/xapi
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv

--
haXe - an open source web programming language
http://haxe.org