Preparing Ryppl Developer Preview based on 0install

[Dave Abrahams]

Hi All,

I have committed to showing something based on 0install and cmake at the
BoostCon/C++Now conference in May:
http://cppnow.org/session/cmake-modularization-and-ryppl-developer-preview/
The only reason 0install isn't mentioned in the description is that it
wouldn't be meaninful to most of the audience, which hasn't heard of
0install yet.  I actually see 0install as being far more important to the
Ryppl project than cmake or git is.  In principle, in a 0install ecosystem,
people can use whatever build system and VCS they want.  0install is the
irreplaceable element.

Now here's the paragraph where I try to convince you of why you should
care... :-).  Namely, if this project is successful, it's going to be
important to lots of people, and it's going to make 0install much more
important than it is today.  Boost, the primary proof-of-concept for
Ryppl, is a hugely popular project.  We were recently SourceForge's
February Project of the Month
(http://sourceforge.net/blog/potm-20120-boost/), an honor based on the
number of downloads they serve for us.  Being successful for Boost is
already enough to make a big difference in 0install's uptake, but the
goals of Ryppl are much bigger.  Per http://ryppl.org, our stated aim is
"to create the conditions for a portable, modular, C++ software
ecosystem."  Which means that 0install could become relevant to anyone
writing or using C++-based software. (**) Another recent and relevant
event includes an industry effort across Microsoft, Apple, and Google to
push out more internal C++ libraries as open source; they'll need
infrastructure if that effort is to succeed.

I'm writing to ask for your responsiveness and support (i.e. answering
questions and engaging in discussion) over the next 6 weeks as the Ryppl
project prepares for its big debut.  Of course I realize that everyone
here is working as a volunteer, and has other priorities as well, so I
appreciate anything you can do.  I believe there is a unique opportunity
here to make a difference in the world, and I hope the ZI developer
community will join me in doing so.

Regards, and thanks for listening,
Dave

(**) I actually believe that part of the reason there is no portable,
modular, C++ software ecosystem today is that C++ generates some
specific needs that are not exemplified by systems written in other
languages (Marco Jez' excellent thread on this list
<http://j.mp/zi-for-cpp-marco-jez> details some of these), and therefore
Ryppl or 0install may well turn into a generally dominant system
independent of language... but let's not get *too* far ahead of
ourselves ;-)

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Zsolt Dollenstein-3]

I'm happy to devtest anything you have and provide feedback; I have
been following ryppl silently for the past 2-3 months and I think
0install would be the perfect tool for the job.

Zsolt

On Mon, Apr 2, 2012 at 7:50 PM, Dave Abrahams <dave@...> wrote:

>
> Hi All,
>
> I have committed to showing something based on 0install and cmake at the
> BoostCon/C++Now conference in May:
> http://cppnow.org/session/cmake-modularization-and-ryppl-developer-preview/
> The only reason 0install isn't mentioned in the description is that it
> wouldn't be meaninful to most of the audience, which hasn't heard of
> 0install yet.  I actually see 0install as being far more important to the
> Ryppl project than cmake or git is.  In principle, in a 0install ecosystem,
> people can use whatever build system and VCS they want.  0install is the
> irreplaceable element.
>
> Now here's the paragraph where I try to convince you of why you should
> care... :-).  Namely, if this project is successful, it's going to be
> important to lots of people, and it's going to make 0install much more
> important than it is today.  Boost, the primary proof-of-concept for
> Ryppl, is a hugely popular project.  We were recently SourceForge's
> February Project of the Month
> (http://sourceforge.net/blog/potm-20120-boost/), an honor based on the
> number of downloads they serve for us.  Being successful for Boost is
> already enough to make a big difference in 0install's uptake, but the
> goals of Ryppl are much bigger.  Per http://ryppl.org, our stated aim is
> "to create the conditions for a portable, modular, C++ software
> ecosystem."  Which means that 0install could become relevant to anyone
> writing or using C++-based software. (**) Another recent and relevant
> event includes an industry effort across Microsoft, Apple, and Google to
> push out more internal C++ libraries as open source; they'll need
> infrastructure if that effort is to succeed.
>
> I'm writing to ask for your responsiveness and support (i.e. answering
> questions and engaging in discussion) over the next 6 weeks as the Ryppl
> project prepares for its big debut.  Of course I realize that everyone
> here is working as a volunteer, and has other priorities as well, so I
> appreciate anything you can do.  I believe there is a unique opportunity
> here to make a difference in the world, and I hope the ZI developer
> community will join me in doing so.
>
> Regards, and thanks for listening,
> Dave
>
> (**) I actually believe that part of the reason there is no portable,
> modular, C++ software ecosystem today is that C++ generates some
> specific needs that are not exemplified by systems written in other
> languages (Marco Jez' excellent thread on this list
> <http://j.mp/zi-for-cpp-marco-jez> details some of these), and therefore
> Ryppl or 0install may well turn into a generally dominant system
> independent of language... but let's not get *too* far ahead of
> ourselves ;-)
>
> --
> Dave Abrahams
> BoostPro Computing
> http://www.boostpro.com
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Zero-install-devel mailing list
> Zero-install-devel@...
> https://lists.sourceforge.net/lists/listinfo/zero-install-devel

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Tim Cuthbertson-2]

I don't do much C++, so probably would be of little use (although I
can probably handle some 0install noob questions ;)). But I do think
it would be excellent for a widely popular _something_ to be built on
/ distributed via 0install, so good luck!

On Tue, Apr 3, 2012 at 4:01 AM, Zsolt Dollenstein <zsol.zsol@...> wrote:

> I'm happy to devtest anything you have and provide feedback; I have
> been following ryppl silently for the past 2-3 months and I think
> 0install would be the perfect tool for the job.
>
> Zsolt
>
> On Mon, Apr 2, 2012 at 7:50 PM, Dave Abrahams <dave@...> wrote:
>>
>> Hi All,
>>
>> I have committed to showing something based on 0install and cmake at the
>> BoostCon/C++Now conference in May:
>> http://cppnow.org/session/cmake-modularization-and-ryppl-developer-preview/
>> The only reason 0install isn't mentioned in the description is that it
>> wouldn't be meaninful to most of the audience, which hasn't heard of
>> 0install yet.  I actually see 0install as being far more important to the
>> Ryppl project than cmake or git is.  In principle, in a 0install ecosystem,
>> people can use whatever build system and VCS they want.  0install is the
>> irreplaceable element.
>>
>> Now here's the paragraph where I try to convince you of why you should
>> care... :-).  Namely, if this project is successful, it's going to be
>> important to lots of people, and it's going to make 0install much more
>> important than it is today.  Boost, the primary proof-of-concept for
>> Ryppl, is a hugely popular project.  We were recently SourceForge's
>> February Project of the Month
>> (http://sourceforge.net/blog/potm-20120-boost/), an honor based on the
>> number of downloads they serve for us.  Being successful for Boost is
>> already enough to make a big difference in 0install's uptake, but the
>> goals of Ryppl are much bigger.  Per http://ryppl.org, our stated aim is
>> "to create the conditions for a portable, modular, C++ software
>> ecosystem."  Which means that 0install could become relevant to anyone
>> writing or using C++-based software. (**) Another recent and relevant
>> event includes an industry effort across Microsoft, Apple, and Google to
>> push out more internal C++ libraries as open source; they'll need
>> infrastructure if that effort is to succeed.
>>
>> I'm writing to ask for your responsiveness and support (i.e. answering
>> questions and engaging in discussion) over the next 6 weeks as the Ryppl
>> project prepares for its big debut.  Of course I realize that everyone
>> here is working as a volunteer, and has other priorities as well, so I
>> appreciate anything you can do.  I believe there is a unique opportunity
>> here to make a difference in the world, and I hope the ZI developer
>> community will join me in doing so.
>>
>> Regards, and thanks for listening,
>> Dave
>>
>> (**) I actually believe that part of the reason there is no portable,
>> modular, C++ software ecosystem today is that C++ generates some
>> specific needs that are not exemplified by systems written in other
>> languages (Marco Jez' excellent thread on this list
>> <http://j.mp/zi-for-cpp-marco-jez> details some of these), and therefore
>> Ryppl or 0install may well turn into a generally dominant system
>> independent of language... but let's not get *too* far ahead of
>> ourselves ;-)
>>
>> --
>> Dave Abrahams
>> BoostPro Computing
>> http://www.boostpro.com
>>
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Zero-install-devel mailing list
>> Zero-install-devel@...
>> https://lists.sourceforge.net/lists/listinfo/zero-install-devel
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Zero-install-devel mailing list
> Zero-install-devel@...
> https://lists.sourceforge.net/lists/listinfo/zero-install-devel

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Dave Abrahams]

on Mon Apr 02 2012, Zsolt Dollenstein <zsol.zsol-AT-gmail.com> wrote:

> I'm happy to devtest anything you have and provide feedback; I have
> been following ryppl silently for the past 2-3 months and I think
> 0install would be the perfect tool for the job.

Thanks, Zsolt!  I can guarantee I'll be calling on you for this.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Dave Abrahams]

on Mon Apr 02 2012, Tim Cuthbertson <tim-AT-gfxmonk.net> wrote:

> I don't do much C++, so probably would be of little use (although I
> can probably handle some 0install noob questions ;)). But I do think
> it would be excellent for a widely popular _something_ to be built on
> / distributed via 0install, so good luck!

Hi Tim,

Most of what I expect to need help with doesn't require any specific C++
knowledge at all (and I know where to get C++ expertise when I need it),
so I'm sure you can be more helpful than you think.  The main issues are
going to have to do with understanding and using ZI itself and figuring
out how most appropriately to design and integrate new features.

Best Regards,

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Bastian Eicher]

Hi Dave,
something I haven't quite understood yet: How exactly does Ryppl use Zero
Install internally?
Does a call to "ryppl install some_package" go fetch metadata from a Ryppl
repository containing a feed URL which is then used for "0install download
http://some_uri"?
Or is the intention to use Zero Install to provide infrastructure such as a
Git client and CMake?

Regards
Bastian


------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Dave Abrahams]

on Tue Apr 03 2012, "Bastian Eicher" <bastian-AT-eicher.net> wrote:

> Hi Dave,
> something I haven't quite understood yet: How exactly does Ryppl use Zero
> Install internally?
> Does a call to "ryppl install some_package" go fetch metadata from a Ryppl
> repository containing a feed URL which is then used for "0install download
> http://some_uri"?
> Or is the intention to use Zero Install to provide infrastructure such as a
> Git client and CMake?

Thanks for your interest Bastien,

The possibility of using Zero Install to provide infrastructure such as
a Git client and CMake is a major attraction, without a doubt... so
that's part of the scheme.  However, it's not the main focus.

Actually, I'm still trying to discover how Ryppl should use Zero
Install; that's part of what I'll be asking for help with.  At the
moment I am leaning away from anything like "using Zero Install
internally," which would imply some kind of wrapper.  It is a Ryppl
principle to leverage existing tools as much as possible and intercede
as little as possible, so it would be much better, if practical, to
expose users to ZI directly. (**)

Therefore, we might not end up with "ryppl install some_package" at all.
The immediate goal of Ryppl is to provide a framework for smoothly
integrating ZI with CMake and Git, to support a number of common
workflows.  What that framework is exactly is still up in the air, but I
imagine it may consist of templates, documentation/instructions, ZI
packages implementing CMake modules, etc.

The only thing I can see right now that *might* push us in the direction
of some kind of wrapper is if ZI turns out to be hostile to natively
supporting some kind of "blessed feed alias catalogs."  One of the first
things I want to discuss here is whether/how such catalogs could be
supported within ZI.  I envision 0installing (meaning 0install download
plus some kind of activation step) catalogs that map short names onto
URIs, allowing users therafter to substitute the short names for the
URIs in all 0install commands.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Thomas Leonard-3]

On Apr 2, 2012 6:51 PM, "Dave Abrahams" <dave@...> wrote:
>
>
> Hi All,
>
> I have committed to showing something based on 0install and cmake at the
> BoostCon/C++Now conference in May:
> http://cppnow.org/session/cmake-modularization-and-ryppl-developer-preview/
> The only reason 0install isn't mentioned in the description is that it
> wouldn't be meaninful to most of the audience, which hasn't heard of
> 0install yet.  I actually see 0install as being far more important to the
> Ryppl project than cmake or git is.  In principle, in a 0install ecosystem,
> people can use whatever build system and VCS they want.  0install is the
> irreplaceable element.
>
> Now here's the paragraph where I try to convince you of why you should
> care... :-).  Namely, if this project is successful, it's going to be
> important to lots of people, and it's going to make 0install much more
> important than it is today.  Boost, the primary proof-of-concept for
> Ryppl, is a hugely popular project.  We were recently SourceForge's
> February Project of the Month
> (http://sourceforge.net/blog/potm-20120-boost/), an honor based on the
> number of downloads they serve for us.  Being successful for Boost is
> already enough to make a big difference in 0install's uptake, but the
> goals of Ryppl are much bigger.  Per http://ryppl.org, our stated aim is
> "to create the conditions for a portable, modular, C++ software
> ecosystem."  Which means that 0install could become relevant to anyone
> writing or using C++-based software. (**) Another recent and relevant
> event includes an industry effort across Microsoft, Apple, and Google to
> push out more internal C++ libraries as open source; they'll need
> infrastructure if that effort is to succeed.
>
> I'm writing to ask for your responsiveness and support (i.e. answering
> questions and engaging in discussion) over the next 6 weeks as the Ryppl
> project prepares for its big debut.  Of course I realize that everyone
> here is working as a volunteer, and has other priorities as well, so I
> appreciate anything you can do.  I believe there is a unique opportunity
> here to make a difference in the world, and I hope the ZI developer
> community will join me in doing so.

Hi Dave, that sounds great!

I think together we should be able to answer questions quite quicky, especially beginner ones. It's mainly the "when are you going to implement x?" questions that don't get quicky replies, because people don't like to promise things they might not have time to do...

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Dave Abrahams]

on Wed Apr 04 2012, Thomas Leonard <talex5-AT-gmail.com> wrote:

> Hi Dave, that sounds great!
>
> I think together we should be able to answer questions quite quicky,
> especially beginner ones. It's mainly the "when are you going to
> implement x?" questions that don't get quicky replies, because people
> don't like to promise things they might not have time to do...

Well, I think I have enough experience with ZI now to not be asking
/too/ many beginner questions... and I don't expect to ask when you are
going to implement any features.  The kinds of questions I expect to ask
are:

 * I want to add capability XXX to 0install: please help me figure out
   how to do it in a way that's consistent with ZI's goals and design
   philosophy.

 * I want to make it really convenient to do job XXX with 0install.
   What instructions should I give people?

etc...

In other words, I expect to require help with 0install's design and its
vision for how things get done.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Bastian Eicher]

> One of the first
> things I want to discuss here is whether/how such catalogs could be
> supported within ZI.  I envision 0installing (meaning 0install download
> plus some kind of activation step) catalogs that map short names onto
> URIs, allowing users therafter to substitute the short names for the
> URIs in all 0install commands.

We have this non-formalized metafeed/catalog concept which is currently used
by the Windows version of Zero Install to provide the list of available
applications in the GUI. The format looks roughly like this:
<catalog>
        <interface uri="http://some/where">
                Stripped down version of the original feed
        </interface>
        <interface uri="http://another/place">
                Stripped down version of the original feed
        </interface>
        ...
</catalog>
The catalog duplicates metadata required for an application overview (stuff
like names, categories, descriptions, icons) but not specific
implementations, dependencies, etc..
Zero Install for Windows currently loads a single catalog from
http://0install.de/catalog/ but I intend to allow users to add custom
catalog sources in a future version (something like "0install
register-catalog URI").

We could add a short-name="" attribute to the <interface> elements and have
"0install select/download/run" look through all short names in registered
catalogs whenever an interface can't be interpreted as an URL or local file
path.
Currently the catalogs are not signed and retrieved via HTTP. We would need
to add some form of protection before giving catalogs the power to provide
name mapping.


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Dave Abrahams]

on Mon Apr 16 2012, "Bastian Eicher" <bastian-AT-eicher.net> wrote:

>> One of the first
>> things I want to discuss here is whether/how such catalogs could be
>> supported within ZI.  I envision 0installing (meaning 0install download
>> plus some kind of activation step) catalogs that map short names onto
>> URIs, allowing users therafter to substitute the short names for the
>> URIs in all 0install commands.
>
> We have this non-formalized metafeed/catalog concept which is currently used
> by the Windows version of Zero Install to provide the list of available
> applications in the GUI. The format looks roughly like this:
> <catalog>
> <interface uri="http://some/where">
> Stripped down version of the original feed
> </interface>
> <interface uri="http://another/place">
> Stripped down version of the original feed
> </interface>
> ...
> </catalog>

So now we have at least three informal ways of doing this:
yours, gfxmonk.net/dist/0install/index, and what Anders described.  It's
probably time to standardize on something :-)

> The catalog duplicates metadata required for an application overview (stuff
> like names, categories, descriptions, icons) but not specific
> implementations, dependencies, etc..
> Zero Install for Windows currently loads a single catalog from
> http://0install.de/catalog/ but I intend to allow users to add custom
> catalog sources in a future version (something like "0install
> register-catalog URI").
>
> We could add a short-name="" attribute to the <interface> elements and have
> "0install select/download/run" look through all short names in registered
> catalogs whenever an interface can't be interpreted as an URL or local file
> path.
> Currently the catalogs are not signed and retrieved via HTTP. We would need
> to add some form of protection before giving catalogs the power to provide
> name mapping.

I was thinking the catalogs themselves could just be zeroinstall
packages and thus benefit from all the protections we already have (?)

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Anders F Björklund-3]

Dave Abrahams wrote:

> on Mon Apr 16 2012, "Bastian Eicher" <bastian-AT-eicher.net> wrote:
>
>>> One of the first
>>> things I want to discuss here is whether/how such catalogs could be
>>> supported within ZI.  I envision 0installing (meaning 0install download
>>> plus some kind of activation step) catalogs that map short names onto
>>> URIs, allowing users therafter to substitute the short names for the
>>> URIs in all 0install commands.
>>
>> We have this non-formalized metafeed/catalog concept which is currently used
>> by the Windows version of Zero Install to provide the list of available
>> applications in the GUI. The format looks roughly like this:
>> <catalog>
>> <interface uri="http://some/where">
>> Stripped down version of the original feed
>> </interface>
>> <interface uri="http://another/place">
>> Stripped down version of the original feed
>> </interface>
>> ...
>> </catalog>
>
> So now we have at least three informal ways of doing this:
> yours, gfxmonk.net/dist/0install/index, and what Anders described.  It's
> probably time to standardize on something :-)

My <index> was at http://afb.users.sourceforge.net/zero-install/index/
The original <list> is here: http://0install.net/injector-feeds.html

It comes with some scripts, to generate from the original feed lists:
http://zero-install.git.sourceforge.net/git/gitweb.cgi?p=zero-install/htdocs;a=tree;f=lists

lists/%.xml: lists/%.lst
        ./lists/make-list.py $<

Then the web page is rendered by an XSL template from the XML, as usual.
It would be nice if these were standardized into a single format, yes...

--anders


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Bastian Eicher]

> My <index> was at http://afb.users.sourceforge.net/zero-install/index/
> ...
> Then the web page is rendered by an XSL template from the XML, as usual.
> It would be nice if these were standardized into a single format, yes...
The <catalog> format and the accompanying XSL template is basically just a
slight modification of your <index> format.

I do not group interfaces by categories. Instead I simply leave the
<category> tags within the <interface> tags.
I chose to do this for two reasons:
* Feeds can specify more than one category.
* When I programmatically parse the XML I sometimes need to process and sort
the entries based on some criteria other than their category. In these cases
collapsing the multiple <category> sublists into a flat list before going
through the entries feels a little awkward.
Grouping by categories in the index does of course have the nice advantage
of producing a much more human-friendly output in the browser.

The <catalog> format uses xml:lang to store localized <summary>s and
<description>s like the feed format itself.

The only other difference is that the root tag is named <catalog> instead of
<index> and has a different XML namespace.


------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Dave Abrahams]

on Mon Apr 16 2012, "Bastian Eicher" <bastian-AT-eicher.net> wrote:

>> My <index> was at http://afb.users.sourceforge.net/zero-install/index/
>> ...
>> Then the web page is rendered by an XSL template from the XML, as usual.
>> It would be nice if these were standardized into a single format,
>> yes...
>
> The <catalog> format and the accompanying XSL template is basically just a
> slight modification of your <index> format.
>
> I do not group interfaces by categories. Instead I simply leave the
> <category> tags within the <interface> tags.
>
> I chose to do this for two reasons:
> * Feeds can specify more than one category.

Oh!  I hadn't noticed the "*"s in the feed specification.  Glad you
pointed that out.

> * When I programmatically parse the XML I sometimes need to process and sort
> the entries based on some criteria other than their category. In these cases
> collapsing the multiple <category> sublists into a flat list before going
> through the entries feels a little awkward.
> Grouping by categories in the index does of course have the nice advantage
> of producing a much more human-friendly output in the browser.

I think true human-friendliness will only be reached with server-side
and/or client-side (javascript) code that gives flexible searching,
filtering, and other facilities like ratings and/or download counts
anyhow, so IMO you made the right trade-off.

> The <catalog> format uses xml:lang to store localized <summary>s and
> <description>s like the feed format itself.

Nice... but I don't see any mention of xml:lang in the feed format docs(?)

> The only other difference is that the root tag is named <catalog> instead of
> <index> and has a different XML namespace.

So, are there any objections to Bastien's format?  Thomas, would you
consider making it part of the 0install "standard?"

Thanks,

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Antonio Orlando]

On Wed, 18 Apr 2012 16:52:35 +0200, Dave Abrahams <dave@...>  
wrote:

> So, are there any objections to Bastien's format?  Thomas, would you
> consider making it part of the 0install "standard?"

This was a call for objections, but I will dare raising my hand just to  
say that I fully support this request.

--
Antonio

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Tim Cuthbertson-2]

On Thu, Apr 19, 2012 at 12:52 AM, Dave Abrahams <dave@...> wrote:

>
> on Mon Apr 16 2012, "Bastian Eicher" <bastian-AT-eicher.net> wrote:
>
>>> My <index> was at http://afb.users.sourceforge.net/zero-install/index/
>>> ...
>>> Then the web page is rendered by an XSL template from the XML, as usual.
>>> It would be nice if these were standardized into a single format,
>>> yes...
>>
>> The <catalog> format and the accompanying XSL template is basically just a
>> slight modification of your <index> format.
>>
>> I do not group interfaces by categories. Instead I simply leave the
>> <category> tags within the <interface> tags.
>>
>> I chose to do this for two reasons:
>> * Feeds can specify more than one category.
>
> Oh!  I hadn't noticed the "*"s in the feed specification.  Glad you
> pointed that out.
>
>> * When I programmatically parse the XML I sometimes need to process and sort
>> the entries based on some criteria other than their category. In these cases
>> collapsing the multiple <category> sublists into a flat list before going
>> through the entries feels a little awkward.
>> Grouping by categories in the index does of course have the nice advantage
>> of producing a much more human-friendly output in the browser.
>
> I think true human-friendliness will only be reached with server-side
> and/or client-side (javascript) code that gives flexible searching,
> filtering, and other facilities like ratings and/or download counts
> anyhow, so IMO you made the right trade-off.
>
>> The <catalog> format uses xml:lang to store localized <summary>s and
>> <description>s like the feed format itself.
>
> Nice... but I don't see any mention of xml:lang in the feed format docs(?)
>
>> The only other difference is that the root tag is named <catalog> instead of
>> <index> and has a different XML namespace.
>
> So, are there any objections to Bastien's format?  Thomas, would you
> consider making it part of the 0install "standard?"

Sounds good, a couple of minor points though:

<entry-point>

What are these, and do we need them on an index?
It may be used for distinguishing libraries from commands, which is a
good idea. But if that's the purpose I would expect to just see a list
of the <command> tags (probably omitting the path and runner
information for brevity, but I'm not bothered if it stays in)

<description>

my descriptions can be pages long (often the full contents of a
README). I guess that can just be clipped at render-time? Or even
generation time, as long as it's OK that this is not exactly the same
as the feed's actual <description>.

Cheers,
 - Tim.

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Bastian Eicher]

> <entry-point>
>
> What are these, and do we need them on an index?
> It may be used for distinguishing libraries from commands, which is a
> good idea. But if that's the purpose I would expect to just see a list
> of the <command> tags (probably omitting the path and runner
> information for brevity, but I'm not bothered if it stays in)

<command> tags are located within specific implementations. Not all versions
of an application necessarily provide the same commands.
The intention of <entry-point>s is to provide a feed-level list of available
commands along with optional icons and localizable descriptions. (The
binary-name tag is used as a hint for a suitable alias name.) They are
mainly used by the Windows desktop integration system but I believe the data
would be equally applicable to 0desktop.
In short: An <entry-point> describes what an application can do and a
<command> describes how to get it to do just that.

The Zero Install for Windows GUI uses the <entry-point>s to populate a
"Select command" dialog box. In order to be able to display this dialog box
in the "New applications" list before retrieving individual feeds and since
the <entry-point>s do not describe anything implementation-specific I
decided to add them to the catalog.


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Bastian Eicher]

> Nice... but I don't see any mention of xml:lang in the feed format docs(?)
Indeed. Both the Python and Windows versions of Zero Install have code in
place that handles localized versions of <description>s and <summary>s -
discussed on this mailing list quite some time ago - but it's not yet
mentioned in the official documentation.


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Tim Cuthbertson-2]

On Thu, Apr 19, 2012 at 9:52 PM, Bastian Eicher <bastian@...> wrote:

>> <entry-point>
>>
>> What are these, and do we need them on an index?
>> It may be used for distinguishing libraries from commands, which is a
>> good idea. But if that's the purpose I would expect to just see a list
>> of the <command> tags (probably omitting the path and runner
>> information for brevity, but I'm not bothered if it stays in)
>
> <command> tags are located within specific implementations. Not all versions
> of an application necessarily provide the same commands.
> The intention of <entry-point>s is to provide a feed-level list of available
> commands along with optional icons and localizable descriptions. (The
> binary-name tag is used as a hint for a suitable alias name.) They are
> mainly used by the Windows desktop integration system but I believe the data
> would be equally applicable to 0desktop.
> In short: An <entry-point> describes what an application can do and a
> <command> describes how to get it to do just that.

I'd prefer to combine this with the <command> tag (by adding a few
optional tags/attributes like "binary-name" and descriptions), so we
don't have to repeat ourselves. I don't think the problem of commands
differing across implementations can't actually be be avoided either
way - if you add, remove or change an entry-point as of a certain
release, older implementations will not actually support it - so you
might as well just get the list of commands from the latest
implementation as a *guide* to what commands an interface most likely
supports, which I think is the best you can do regardless of whether
you use implementation-level or feed-level elements.

> The Zero Install for Windows GUI uses the <entry-point>s to populate a
> "Select command" dialog box. In order to be able to display this dialog box
> in the "New applications" list before retrieving individual feeds and since
> the <entry-point>s do not describe anything implementation-specific I
> decided to add them to the catalog.

What happens if you pick an entry point that isn't actually supported
by the impl that is later selected?

Cheers,
 - Tim.

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

[Bastian Eicher]

> I'd prefer to combine this with the <command> tag (by adding a few
> optional tags/attributes like "binary-name" and descriptions), so we
> don't have to repeat ourselves. I don't think the problem of commands
> differing across implementations can't actually be be avoided either
> way - if you add, remove or change an entry-point as of a certain
> release, older implementations will not actually support it - so you
> might as well just get the list of commands from the latest
> implementation as a *guide* to what commands an interface most likely
> supports, which I think is the best you can do regardless of whether
> you use implementation-level or feed-level elements.

How do you determine which implementation is the "latest"? Listed last in
the feed file? Highest version number? Preferred by the solver?
I like the expression " guide to what commands an interface most likely
supports". That is exactly what I intend the entry points to be.
I agree that duplication is a bad thing but I don't really think this
qualifies. The entry-points do not store any command-specific data beyond
the command-name.
Two different implementations may provide equivalent functionality (and have
the same command names) but do so in a different fashion internally (e.g.,
one using a runner and the other executing a binary directly). The entry
points allow a feed author to specify which command names to advertise to
the user without having to rely on some heuristic to pick up on the "right"
commands.

> What happens if you pick an entry point that isn't actually supported by
> the impl that is later selected?
Selecting an entry point causes "0launch --command=SELECTED_COMMAND URI" to
be executed. Therefore the solver will only consider implementations that
support the selected command.


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel@...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel