-----Original Message-----
From: Crosswalk-dev [mailto:[email protected]]
On Behalf Of Max Waterman
Sent: Monday, March 17, 2014 6:44 PM
To: Wang, Shiliu; Balestrieri, Francesco;
[email protected]
Subject: Re: [Crosswalk-dev] Proposal on how to organize our download binaries
for public users
On 17/03/14 06:27, Wang, Shiliu wrote:
Max, Thanks for your comments.
Agree with you on using the same archiving tools for all archives.
OK, great :)
For your second comment, it's more about the inner structure of
xwalk_app_template, right?
Yes, I think so, though the principle it true of many things, I suppose.
I'm not familiar with apk-generator, will it be eventually part of crosswalk
release?
I hope so, but I'm not privy to the thinking of the decision makers :)
It is part of crosswalk in some sense already, as is grunt-crosswalk - at least
it is
implied because it is part of the github 'organisation' :
<https://github.com/crosswalk-project/crosswalk-apk-generator>
<https://github.com/crosswalk-project/grunt-crosswalk>
I understand there has been some interest voiced at recent conferences for
these tools, so perhaps it will be made more obvious.
It is true that it has been developed independently, by Elliot and myself,
since we
have been convinced that people other than just us would want it and we have
had trouble convinced others :)
Or it's an independent tool which automatically upgrade the xwalk archive it
will
be using? If it's the second case, I think it's necessary to think about if
there need
some protocol between xwalk output and apk-generator.
No, I don't think that describes its purpose (though there is a download tool
included). The tools are basically node/javascript alternatives to the
make_apk.py python-based tool and integrate much more seamlessly with the
node and grunt development environments oft used by html5 application
developers (ourselves included). We haven't attempted to match the
functionality as such, but rather add features that we see as necessary.
In any case, I suspect crosswalk-apk-generator will be just one such tool that
depends on the crosswalk application template download and so the problem I
describe could be mitigated by having a single file describing where the
important
bits are (in json, of course ;)). I suppose it is possible that the make_apk.py
(and
the other python
scripts) could also make use of such a file(?).
However, at the end of the day, it's not a huge deal for us since our
development
cycle is quite light-weight and quick, and crosswalk-apk-generator has a test
suite
to give confidence when making changes; it'd just make things easier, that's
all :)
Max.
Thanks,
Shiliu.
From: Crosswalk-dev
[mailto:[email protected]] On Behalf
Of Balestrieri, Francesco
Sent: Friday, March 14, 2014 6:45 PM
To: Waterman, Max; [email protected]
Subject: Re: [Crosswalk-dev] Proposal on how to organize our download
binaries for public users
? I question the use of multiple archiving tools - ie why some things are
.tar.gz
and some are .zip?
Agree with Max, it seems odd.
From: Crosswalk-dev
[mailto:[email protected]] On Behalf
Of Max Waterman
Sent: Friday, March 14, 2014 12:03 PM
To:
[email protected]<mailto:[email protected]
rosswalk-project.org>
Subject: Re: [Crosswalk-dev] Proposal on how to organize our download
binaries for public users
A couple of thoughts :
1) I question the use of multiple archiving tools - ie why some things are
.tar.gz
and some are .zip? IMO, it would be better to use just a single tool for this
so that
only one is required on users' systems and only one is needed for tools that
automatically download/unpack the archive. In my experience (not crosswalk
specifically), zip has caused many different problems. I'm not sure why, but I
suppose because it has so many different options/compression methods.
Perhaps it's possible to only use the basic compression methods or some other
way of ensuring the downloads are compatible with old zip libs/utilities.
2) We (crosswalk-apk-generator) were recently 'hit' by a change in name of one
of the components that are included in the template download. In this case, it
was simple to fix, but I wonder if there might be a better way - Elliot
suggested
that each download contains a file (manifest.json?) that lists the paths to each
component that are needed so that they can be changed/moved and tools can
continue to work. Perhaps such a thing could be considered.
I suppose I might have not fully understood Elliot's suggestion, but I like that
things would work without changes or with minimal changes, and that tools don't
require intimate knowledge of the internal structure of the archive, instead
just
looking for a single file in the root.
Thanks,
Max.
On 14/03/14 05:49, Yu, Zhiqiang wrote:
The only nitpick I have is about the "xwalk_app_template" name, it's too
"implementation dependent"...
Agree w/ Francesco.. :)
Thanks,
Zhiqiang
" Simplicity is Beauty..."
From: Balestrieri, Francesco
Sent: Friday, March 14, 2014 1:47 PM
To: Wang, Shiliu; Kubo Da Costa, Raphael; Hu, Ningxin; Zhu, Yongsheng
Cc: Yu, Zhiqiang;
[email protected]<mailto:[email protected]
rosswalk-project.org>
Subject: RE: Proposal on how to organize our download binaries for
public users
Shiliu: Totally agree with you. With the new structure.
If a developer wants to directly develop based on Crosswalk, he needs
to
1. Download xwalk_app_template.tar.gz directly.
2. Unzip the tarball
3. Cd xwalk_app_template
4. Create manifest if he wants to.
5. Run make_apk.py according to wiki
6. Publish the generated apk.
Thanks. The only nitpick I have is about the "xwalk_app_template"
name, it's too "implementation dependent". If this is the only package a
developer needs to create Crosswalk apps, it should just be named Crosswalk (or
crosswalk-tool or something self-explanatory like that. But just "crosswalk"
would be best).
Francesco
From: Wang, Shiliu
Sent: Friday, March 14, 2014 7:37 AM
To: Balestrieri, Francesco; Kubo Da Costa, Raphael; Hu, Ningxin; Zhu,
Yongsheng
Cc: Yu, Zhiqiang;
[email protected]<mailto:[email protected]
rosswalk-project.org>
Subject: RE: Proposal on how to organize our download binaries for
public users
Hi, Francesco
Thanks for the comments. See my answer below.
- somewhere else we are discussing the need for a single
tool/package for both ARM and IA. So eventually would the ARM and x86 folders
merge into one?
Shiliu: For xwalk_app_template, yes. But for cordova.tar.gz and other apks,
arm and x86 will still be separated.
- I didn't understand the purpose of "Canary1", "Canary2" etc
Shiliu: "Canary1" and "Canary2" are just short for different versions. I was
just
using 1,2,3 to replace real version number like 5.34.99.0. Sorry for the
confusing.
- In my opinion we should bake Cordova support in the main
crosswalk archive as well
Shiliu: yes, that's cordova.tar.gz. for. You might take the first two colored
structures as my proposal, they are the current status. My proposal is the last
one. I should use some different color, sorry for the misleading.
Android/
Canary/
Canary1/
Xwalk_app_tempalte.tar.gz
X86/
Cordova.tar.gz
Xwalk.zip (including runtimelib and
helloworld)
Xwalk_tests.zip (including tests apk and
shell apk)
arm/
Cordova.tar.gz
Xwalk.zip (including runtimelib and
helloworld)
Xwalk_tests.zip (including tests apk and
shell apk)
Canary2/
Similar to canary1
Beta/
Similar to Canary
What I think we should aim for is that a developer who wants to use Crosswalk
needs to follow something like these steps:
- download and unzip package
- if needed, give one install command
- cd to their web or Cordova app
- if needed, create a manifest
- run package script
- Publish to app store
Shiliu: Totally agree with you. With the new structure.
If a developer wants to directly develop based on Crosswalk, he needs
to
1. Download xwalk_app_template.tar.gz directly.
2. Unzip the tarball
3. Cd xwalk_app_template
4. Create manifest if he wants to.
5. Run make_apk.py according to wiki
6. Publish the generated apk.
Exactly like what you suggest. :)
If he wants to adopt cordova container, steps are probably the same, just he
needs to download different package for arm/x86.
The main idea is to host each tool separately instead of merge them in a super
large zip. The pros is to have less download size for end user and less steps to
extract the super zip.
Thanks,
Shiliu.
From: Balestrieri, Francesco
Sent: Friday, March 14, 2014 1:09 PM
To: Wang, Shiliu; Kubo Da Costa, Raphael; Hu, Ningxin; Zhu, Yongsheng
Cc: Yu, Zhiqiang;
[email protected]<mailto:[email protected]
rosswalk-project.org>
Subject: RE: Proposal on how to organize our download binaries for
public users
Hi,
a few comments:
- somewhere else we are discussing the need for a single
tool/package for both ARM and IA. So eventually would the ARM and x86 folders
merge into one?
- I didn't understand the purpose of "Canary1", "Canary2" etc
- In my opinion we should bake Cordova support in the main
crosswalk archive as well
What I think we should aim for is that a developer who wants to use Crosswalk
needs to follow something like these steps:
- download and unzip package
- if needed, give one install command
- cd to their web or Cordova app
- if needed, create a manifest
- run package script
- Publish to app store
From: Wang, Shiliu
Sent: Friday, March 14, 2014 4:45 AM
To: Balestrieri, Francesco; Kubo Da Costa, Raphael; Hu, Ningxin; Zhu,
Yongsheng
Cc: Yu, Zhiqiang;
[email protected]<mailto:[email protected]
rosswalk-project.org>
Subject: Proposal on how to organize our download binaries for public
users
Hi, All
Per https://crosswalk-project.org/jira/browse/XWALK-898 ,
https://crosswalk-project.org/jira/browse/XWALK-1013,
https://crosswalk-project.org/jira/browse/XWALK-670 .
They are all about the requirement for the binaries we deliver to public.
Currently our binaries are organized like Android_arm/ Canary/
Canary1.zip Canary2.zip
Beta/
Beta1.zip Android_x86/
Canary/
Canary1.zip
Beta/
Beta1.zip And within the zip it will
be:
Crosswalk-version-arch.zip/
Apks/
Bunch of apks.
Xwalk_app_template.tar.gz
Xwalk_core_library.tar.gz
From the Jira issues, the requirement is to:
1. Provide cordova.tar.gz for download, which is basically
crosswalk_cordova_android code + xwalk_core_library.tar.gz .
2. Provide one xwalk_app_template.tar.gz for both x86 and arm.
Based on following facts:
1. Xwalk_app_template.tar.gz is enough for web developer to use
xwalk.
2. Cordova.tar.gz is also functional independent itself.
I propose to organize our release to public following way Android/
Canary/ Canary1/
Xwalk_app_tempalte.tar.gz
X86/
Cordova.tar.gz
Xwalk.zip (including runtimelib and
helloworld)
Xwalk_debug.zip (including tests apk
and shell apk)
arm/
Cordova.tar.gz
Xwalk.zip (including runtimelib and
helloworld)
Xwalk_debug.zip (including tests apk
and shell apk)
Canary2/
Similar to canary1
Beta/
Similar to Canary
The gaps from current status will be
1. Generate cordova.tar.gz
2. Generate one xwalk_app_template.tar.gz including both archs native
libraries.
3. Reorganize the folder structure.
Thanks,
Shiliu.
_______________________________________________
Crosswalk-dev mailing list
[email protected]<mailto:[email protected]
rosswalk-project.org>
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki Business Identity Code:
0357606 - 4 Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Crosswalk-dev mailing list
[email protected]
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
