Opening up CXAN
Chris Maloney
> ** CXAN
>
> CXAN is not EXPath. It uses EXPath, at least its packaging system.
> But I think this is a very important piece in the XML landscape.
> Technically, the website still needs some improvements in order to be
> ready for real collaboration.
This is the most important link in the chain, in my opinion. CXAN could
potentially be the hub of our collaboration efforts, but it is way too
stagnant, and it is way too closed. The site itself doesn't seem to have
been updated in any significant way in a long time, and perhaps a big part
of the reason is that you don't have time. So my specific suggestion is
this: open up CXAN by moving the entire set of website files to Github
and inviting direct collaboration there.
I know that servlex, which CXAN is supposed to be based on, is on
Google code (http://code.google.com/p/servlex/). But the servlex project
itself seems also to be pretty stagnant. I'd suggest merging servlex with
CXAN into the same project. The code itself could still be kept encapsulated,
with CXAN as a reference implementation of servlex. But I think they are
close enough in scope, and the pool of collaborators has yet to materialize,
so they should be merged.
> But regarding the very, very few requests to add a new package to
> CXAN, I really don't think this is an issue, yet.
Florent, I don't think you appreciate how big of a barrier it is for the
average developer to see, "If you want to add a library ..., you can send
an email ...". Most people, I think (certainly me), would like to play
around with something on our own, before engaging an email list or an author.
For me, I can say that I'm usually a little shy, don't want to bother
people, especially if I am still in the learning stage of something.
David Carlisle did a great job of describing that the purpose of CTAN, for
example, is to be a very open, and comprehensive collection of modules. In
your reply, you didn't take issue with this concept. So I'd suggest that
it's very important that the barrier to entry for CXAN be lowered. And the
way to do that is to fix the website to allow users to upload and share
their stuff autonomously. And, again, the way to fix the website is to allow
others to collaborate on it, directly.
> One of the central and important feature of CXAN is that it gives a
> unique short name to each package, .... So the idea is that the
> maintainer of a package (its implementer for instance) must ask to
> add the package to CXAN.
It seems to me there is overlap between your desire to maintain the
quality of the EXPath specs and the sanctity of these CXAN short names.
But what is missing is that there needs to be a way for developers to
upload and share alpha-quality (or less) modules, to try things out, and
to provide the basis for collaboration. I would suggest a namespaced
system, with user names used as prefixes. So I could upload
"klortho:sandbox", for example, and thus have something that I could try
out and share with others. Then, later, if others voted that my sandbox
was the best sandbox, then it could be promoted to the non-prefix space.
But without this kind of mechanism, then I think we can't expect there
ever to be many more modules added -- the barrier to entry is too high.
Also, a prefix/namespace system would let me have complete control over a
set of related packages, for example, jats (hmm, it seems to me that we
had this discussion before ....)
> The system itself is also design from the beginning to be able to
> setup another repository, so instead of or in addition to the
> "official" CXAN repository at cxan.org, one can setup another repo
> (e.g. local to a company or to address a specific domain or to build a
> specific "distribution"...)
This is nice, but it's not going to happen. One of the benefits of
CXAN is that it's a central place for people to share modules. Each module
there would benefit from the network effect. There would be no benefit, at
present, that I can imagine, for anyone to set up their own CXAN repository.
In fact, there's a strong argument not to do it: the potential for
name-conflicts.
> If you have a library/application/set of schemas/anything else that
> you'd like to add to CXAN, please tell me.
That's not good enough, for reasons already stated. CXAN must be opened
up, or it will just not work.
Thanks for being open to this discussion! And, of course, thanks for all
the great software and ideas!
Chris
Florent Georges
> Florent wrote:
Hi,
>> CXAN is not EXPath. [...]
> This is the most important link in the chain, in my opinion. CXAN
> could potentially be the hub of our collaboration efforts, but it is
> way too stagnant, and it is way too closed. The site itself doesn't
> seem to have been updated in any significant way in a long time, and
> perhaps a big part of the reason is that you don't have time. So my
> specific suggestion is this: open up CXAN by moving the entire set
> of website files to Github and inviting direct collaboration there.
a new package is welcome to do so. Technically, this passes by me for
now. With regards to the number of people who asked to upload a new
package, I don't think this is a big problem, really. If you show me
that hundreds, or even dozens of people want to upload a new package
but don't want to send me an email to do so, I will add the feature to
the CXAN website.
> I'd suggest merging servlex with CXAN into the same project.
beasts.
>> But regarding the very, very few requests to add a new package to
>> CXAN, I really don't think this is an issue, yet.
> Florent, I don't think you appreciate how big of a barrier it is for
> the average developer to see, "If you want to add a library ..., you
> can send an email ...". Most people, I think (certainly me), would
> like to play around with something on our own, before engaging an
> email list or an author. For me, I can say that I'm usually a
> little shy, don't want to bother people, especially if I am still in
> the learning stage of something.
add something to CXAN, please tell me so ;-), and 2/ CXAN is aimed at
being a global repository of libraries and applications; so when you
are new and want to play around, and that you are not ready to engage
one single person with an email, the last thing you want to do is to
change the global repository directly and potentially bother all of
its users at once... Especially when you are new to the technology.
But I guess I see your point here. That's less about being able to
upload packages directly the very first time, than about being able to
play around with the technology before, on your own. I think that is
an interesting idea. I am almost ready for a new release of CXAN, I
will try to create a public sandbox at the same time, and maybe to add
an installer too, to install a sandbox on localhost.
> David Carlisle did a great job of describing that the purpose of
> CTAN, for example, is to be a very open, and comprehensive
> collection of modules. In your reply, you didn't take issue with
> this concept. So I'd suggest that it's very important that the
> barrier to entry for CXAN be lowered. And the way to do that is to
> fix the website to allow users to upload and share their stuff
> autonomously.
don't see how giving users direct access will make it more open. That
can be the case if the load is too high, but that is not the case.
> And, again, the way to fix the website is to allow others to
> collaborate on it, directly.
more than welcome to do so :-) Everything is public, make the change
and send a diff to the list.
> But what is missing is that there needs to be a way for developers
> to upload and share alpha-quality (or less) modules, to try things
> out, and to provide the basis for collaboration.
>> The system itself is also design from the beginning to be able to
>> setup another repository, so instead of or in addition to the
>> "official" CXAN repository at cxan.org, one can setup another repo
>> (e.g. local to a company or to address a specific domain or to
>> build a specific "distribution"...)
> This is nice, but it's not going to happen. One of the benefits of
> CXAN is that it's a central place for people to share modules.
sandbox? Or a developer wants to install one on his/her local machine
to play with the technology? ;-)
Thanks for your comments!
Regards,
--
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/
Jim Fuller
devoted time and energy into depx).
It solves the problem of submission by letting everyone submit (via
github fork, or I will help them integrate) and sidesteps the issue of
judging any particular package worthiness. I think the community is
relatively compact that we can circle around 'good stuff' where its
warranted.
I also see http://depx.org being tangentially related to cxan/expath
packages as at some point (when I find the time) I intend to allow
expath xar packages. But for now its just depx (which really is very
similar to expath packaging).
I think Florent's efforts have been heroic but I know how difficult it
can be to try and bring things forward. I would suggest giving http://depx.org
a try to see if we can kick the can down the road.
http://depx.org
https://github.com/xquery/depx
Jim Fuller
Florent Georges
Hi,
> It solves the problem of submission by letting everyone submit (via
> github fork, or I will help them integrate) and sidesteps the issue
> of judging any particular package worthiness.
problem. This at least means the problem is real and affect several
people ;-) Have you tried CXAN before starting it? If yes, what were
the particular reasons you started a new one?
In particular, I don't see how it let everyone submit by using
Github fork. Instead of sending an email, one has to fork on Github,
change his/her local repository, check it in, push it, and (I guess)
make a pull request... still involving the owner of the initial Git
repository. That's (technically) another way for asking for inclusion
of a new package, but that's not fundamentally different I think.
Unless I missed something, of course.
In the meantime, I gave it a try and still try to understand exactly
what it does. From what I've seen, it helps getting the zip files
from the website, and unzip them in a directory. There is no resolving
mechanism. The user still has to deal with the particular paths where
the files are unzipped. So it is more dedicated at installing third-
party files "privately" in a specific project, than installing some
libraries system-wide, isn't it?
Of course, CXAN can be used like that, but that's missing the
central point of the packaging system: an automatic resolution
mechanism for imports between different components (especially those
written by different authors/organizations).
Florent Georges
> On 19 April 2012 04:37, Chris Maloney wrote:
>> But what is missing is that there needs to be a way for developers
>> to upload and share alpha-quality (or less) modules, to try things
>> out, and to provide the basis for collaboration.
> A public sandbox, yes, I think that could help.
page. Credentials are user = test, password = test.