Download page index files

Hello all,

The java.net team have recently migrated their
download.java.net server
from collab.net to Sun. Among other things this change has
caused a
problem with the download pages. We were previously using
.htaccess
files to configure the auto generated directory indexes and
we were
setting headers, custom icons, and column width.

Not taking into account .htaccess files has resulted in
degraded
usability of these pages and they now look like this:

http://download.java.net/communications/
sip-communicator/nightly/debian/

The only way to discern the different versions is to place
the mouse
over them and compare the contents of the browser status bar
(imagine
your grandma doing this?).

This is something that we need to take care of so I was
wondering what
might be the possibilities. Here are some ideas:

- Keep a single nightly build version available for
download. This would
make it easier for users to choose, though the downside is
that if the
latest version has serious issues that have not been
detected by the
tests, it won't be possible for the user to roll back to an
earlier version

- Create scripts that generate our index files. That was
what we were
doing before collab.net enabled .htaccess configuration of
index files
on the old java.net. We could do this but it's quite
painstaking and
error prone. Nonetheless if anyone feels like it - don't
hesitate to
write some. All we need is a generic .sh file that would use
a fixed
header and generate a listing based on the contents of a
directory. The
problem here is that (contrary to the collab.net version of
djn) we have
no ssh access on the download machine (only sftp) so we'd
probably have
to keep a local copy of all the downloadable files, generate
the index
over it and then make sure that it stays in sync with the
contents of
the download server.

- Use an existing tool for generating page indexes. I have
been looking
for something like this for a while but had no success. Is
anyone aware
of an open source tool that would generate html directory
listings? We
still have the same problem as with the above though - we'd
need to run
the tool locally and then copy the index on the site.

- Use another download server (suggestions?)

Any ideas and contributions are most welcome since we really
need to
find away around this.

Cheers
Emil

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Emil,

if we're able to run PHP scripts on the server, there are
some  
existing solutions. From the ones I saw I prefer snif
(http:// 
www.bitfolge.de/snif-en.html - see the live demo). Another
example is  
Autoindex (http://autoindex.so
urceforge.net/).
Snif provides an index.php, which handles the rest
automatically.  
I've tried it and it works like a charm (just copy the first
 
index.php found in the zip to the dir).

As an extra one may provide description for each of the
files. This  
is done with the help of an additional file called
"descript.ion".  
The rest you'll find in the index.php itself.

Hope that helps,
Alex


Le 13 août 07 à 10:12, Emil Ivov a écrit :

> Hello all,
>
> The java.net team have recently migrated their
download.java.net  
> server
> from collab.net to Sun. Among other things this change
has caused a
> problem with the download pages. We were previously
using .htaccess
> files to configure the auto generated directory indexes
and we were
> setting headers, custom icons, and column width.
>
> Not taking into account .htaccess files has resulted in
degraded
> usability of these pages and they now look like this:
>
> http://download.java.net/communications/sip-com
municator/nightly/ 
> debian/
>
> The only way to discern the different versions is to
place the mouse
> over them and compare the contents of the browser
status bar (imagine
> your grandma doing this?).
>
> This is something that we need to take care of so I was
wondering what
> might be the possibilities. Here are some ideas:
>
> - Keep a single nightly build version available for
download. This  
> would
> make it easier for users to choose, though the downside
is that if the
> latest version has serious issues that have not been
detected by the
> tests, it won't be possible for the user to roll back
to an earlier  
> version
>
> - Create scripts that generate our index files. That
was what we were
> doing before collab.net enabled .htaccess configuration
of index files
> on the old java.net. We could do this but it's quite
painstaking and
> error prone. Nonetheless if anyone feels like it -
don't hesitate to
> write some. All we need is a generic .sh file that
would use a fixed
> header and generate a listing based on the contents of
a directory.  
> The
> problem here is that (contrary to the collab.net
version of djn) we  
> have
> no ssh access on the download machine (only sftp) so
we'd probably  
> have
> to keep a local copy of all the downloadable files,
generate the index
> over it and then make sure that it stays in sync with
the contents of
> the download server.
>
> - Use an existing tool for generating page indexes. I
have been  
> looking
> for something like this for a while but had no success.
Is anyone  
> aware
> of an open source tool that would generate html
directory listings? We
> still have the same problem as with the above though -
we'd need to  
> run
> the tool locally and then copy the index on the site.
>
> - Use another download server (suggestions?)
>
> Any ideas and contributions are most welcome since we
really need to
> find away around this.
>
> Cheers
> Emil
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip- 
> communicator.dev.java.net
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Alex,

This is great! I really like the snif project and it would
have been
perfect for us.

The problem is that apparently it doesn't work on
download.java.net.
I've sent a query to the corresponding support mailing list
asking if
PHP support is an option but I don't really have much hope
that it would be.

We could however use Snif as a basis for index generating if
we decide
to create the indexes on the build machine and then copy
them to djn.

Emil

Alexander Pelov wrote:
> Hi Emil,
> 
> if we're able to run PHP scripts on the server, there
are some  
> existing solutions. From the ones I saw I prefer snif
(http:// 
> www.bitfolge.de/snif-en.html - see the live demo).
Another example is  
> Autoindex (http://autoindex.so
urceforge.net/).
> Snif provides an index.php, which handles the rest
automatically.  
> I've tried it and it works like a charm (just copy the
first  
> index.php found in the zip to the dir).
> 
> As an extra one may provide description for each of the
files. This  
> is done with the help of an additional file called
"descript.ion".  
> The rest you'll find in the index.php itself.
> 
> Hope that helps,
> Alex
> 
> 
> Le 13 août 07 à 10:12, Emil Ivov a écrit :
> 
>> Hello all,
>>
>> The java.net team have recently migrated their
download.java.net  
>> server
>> from collab.net to Sun. Among other things this
change has caused a
>> problem with the download pages. We were previously
using .htaccess
>> files to configure the auto generated directory
indexes and we were
>> setting headers, custom icons, and column width.
>>
>> Not taking into account .htaccess files has
resulted in degraded
>> usability of these pages and they now look like
this:
>>
>> http://download.java.net/communications/sip-com
municator/nightly/ 
>> debian/
>>
>> The only way to discern the different versions is
to place the mouse
>> over them and compare the contents of the browser
status bar (imagine
>> your grandma doing this?).
>>
>> This is something that we need to take care of so I
was wondering what
>> might be the possibilities. Here are some ideas:
>>
>> - Keep a single nightly build version available for
download. This  
>> would
>> make it easier for users to choose, though the
downside is that if the
>> latest version has serious issues that have not
been detected by the
>> tests, it won't be possible for the user to roll
back to an earlier  
>> version
>>
>> - Create scripts that generate our index files.
That was what we were
>> doing before collab.net enabled .htaccess
configuration of index files
>> on the old java.net. We could do this but it's
quite painstaking and
>> error prone. Nonetheless if anyone feels like it -
don't hesitate to
>> write some. All we need is a generic .sh file that
would use a fixed
>> header and generate a listing based on the contents
of a directory.  
>> The
>> problem here is that (contrary to the collab.net
version of djn) we  
>> have
>> no ssh access on the download machine (only sftp)
so we'd probably  
>> have
>> to keep a local copy of all the downloadable files,
generate the index
>> over it and then make sure that it stays in sync
with the contents of
>> the download server.
>>
>> - Use an existing tool for generating page indexes.
I have been  
>> looking
>> for something like this for a while but had no
success. Is anyone  
>> aware
>> of an open source tool that would generate html
directory listings? We
>> still have the same problem as with the above
though - we'd need to  
>> run
>> the tool locally and then copy the index on the
site.
>>
>> - Use another download server (suggestions?)
>>
>> Any ideas and contributions are most welcome since
we really need to
>> find away around this.
>>
>> Cheers
>> Emil
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip- 
>> communicator.dev.java.net
>>
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

That's a pity.. snif allows the user to sort the files based
on their  
names, sizes, etc. + the i18n.. If we generate an html file
to be  
later uploaded on download.java.net we have to fix one case
(english,  
sorted by date - for example).

Now, I had some thoughts on this issue, but after going
through all  
cases I think that it became a little too complicated. So, I
guess  
I'll vote for the following solutions (in order of
preference)
1) Generate a single index.html offsite and upload it when
there is a  
new build
2) Keep only the latest file

Alex



PS. Here is the lengthy solution. Feel free to ignore it.

Then maybe we should think of a somewhat mixed solution:
1) Change the web site, so that there is "DOWNLOAD
LATEST VERSION  
(and far far away from it: older versions) ". The
majority of users  
are likely to be just willing to grab the latest version and
not go  
through a list of files trying to figure out which one is
the latest.
2) Keep the current situation for the "older
versions" OR generate a  
single index.html offsite. I think that it's important to
generate a  
file, because some browsers don't have a status bar and
don't show  
the full address of a link.


Now, I see one problem with 1) and it's because the download
page is  
a Wiki (as far as I know). We may overcome this, by adding
an html  
file to download.java.net (such as latest.html), which would
actually  
initiate the download. This way, the DOWNLOAD LATEST VERSION
would  
always point to download.java.net/.../latest.html, which
would know  
which file to download.
A potential problem with this is that the latest
version+date has to  
be added to the Wiki page (so that users know when to
update). I  
don't have enough experience with wikis to say which is the
easiest  
way to accomplish that, but it doesn't seem impossible.


PPS. If the above doesn't seem complex enough, implement it
in C++.

PPPS. If it still doesn't seem a big deal, go see a shrink
;)


Le 13 août 07 à 11:41, Emil Ivov a écrit :

> Alex,
>
> This is great! I really like the snif project and it
would have been
> perfect for us.
>
> The problem is that apparently it doesn't work on
download.java.net.
> I've sent a query to the corresponding support mailing
list asking if
> PHP support is an option but I don't really have much
hope that it  
> would be.
>
> We could however use Snif as a basis for index
generating if we decide
> to create the indexes on the build machine and then
copy them to djn.
>
> Emil
>
> Alexander Pelov wrote:
>> Hi Emil,
>>
>> if we're able to run PHP scripts on the server,
there are some
>> existing solutions. From the ones I saw I prefer
snif (http://
>> www.bitfolge.de/snif-en.html - see the live demo).
Another example is
>> Autoindex (http://autoindex.so
urceforge.net/).
>> Snif provides an index.php, which handles the rest
automatically.
>> I've tried it and it works like a charm (just copy
the first
>> index.php found in the zip to the dir).
>>
>> As an extra one may provide description for each of
the files. This
>> is done with the help of an additional file called
"descript.ion".
>> The rest you'll find in the index.php itself.
>>
>> Hope that helps,
>> Alex
>>
>>
>> Le 13 août 07 à 10:12, Emil Ivov a écrit :
>>
>>> Hello all,
>>>
>>> The java.net team have recently migrated their
download.java.net
>>> server
>>> from collab.net to Sun. Among other things this
change has caused a
>>> problem with the download pages. We were
previously using .htaccess
>>> files to configure the auto generated directory
indexes and we were
>>> setting headers, custom icons, and column
width.
>>>
>>> Not taking into account .htaccess files has
resulted in degraded
>>> usability of these pages and they now look like
this:
>>>
>>> http://download.java.net/communications/sip-com
municator/nightly/
>>> debian/
>>>
>>> The only way to discern the different versions
is to place the mouse
>>> over them and compare the contents of the
browser status bar  
>>> (imagine
>>> your grandma doing this?).
>>>
>>> This is something that we need to take care of
so I was wondering  
>>> what
>>> might be the possibilities. Here are some
ideas:
>>>
>>> - Keep a single nightly build version available
for download. This
>>> would
>>> make it easier for users to choose, though the
downside is that  
>>> if the
>>> latest version has serious issues that have not
been detected by the
>>> tests, it won't be possible for the user to
roll back to an earlier
>>> version
>>>
>>> - Create scripts that generate our index files.
That was what we  
>>> were
>>> doing before collab.net enabled .htaccess
configuration of index  
>>> files
>>> on the old java.net. We could do this but it's
quite painstaking and
>>> error prone. Nonetheless if anyone feels like
it - don't hesitate to
>>> write some. All we need is a generic .sh file
that would use a fixed
>>> header and generate a listing based on the
contents of a directory.
>>> The
>>> problem here is that (contrary to the
collab.net version of djn) we
>>> have
>>> no ssh access on the download machine (only
sftp) so we'd probably
>>> have
>>> to keep a local copy of all the downloadable
files, generate the  
>>> index
>>> over it and then make sure that it stays in
sync with the  
>>> contents of
>>> the download server.
>>>
>>> - Use an existing tool for generating page
indexes. I have been
>>> looking
>>> for something like this for a while but had no
success. Is anyone
>>> aware
>>> of an open source tool that would generate html
directory  
>>> listings? We
>>> still have the same problem as with the above
though - we'd need to
>>> run
>>> the tool locally and then copy the index on the
site.
>>>
>>> - Use another download server (suggestions?)
>>>
>>> Any ideas and contributions are most welcome
since we really need to
>>> find away around this.
>>>
>>> Cheers
>>> Emil
>>>
>>>
------------------------------------------------------------
-------- 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribesip- 
>>> communicator.dev.java.net
>>> For additional commands, e-mail: dev-helpsip-
>>> communicator.dev.java.net
>>>
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip- 
>> communicator.dev.java.net
>>
>>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip- 
> communicator.dev.java.net
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hey Julien,

Thanks for sending this over. I'll wait for the reply from
Sun and I
have also made a query to our university network centre,
asking them
whether it would be possible to host our binaries there (if
it is it
would be a great solution since they have large bandwidth
and we'll have
ssh, php, apache and whatever we need).

If neither of these is an option, then we are probably going
to go for
an off-site indexer, and your script seems like a very good
basis.

Thanks again for sending it!

Cheers
Emil

Julien wrote:
> Hi,
> run PHP script on a Sun server...hum it's probably not
possible,
> an other solution  :
> you can run a php script to generate a index.html file
and upload it
> after (not the best solution :p)
> 
> // connection
> $conn_id = ftp_connect($ftp_server);
> // Identification
> $ftp_id = ftp_login($conn_id, $ftp_user_name,
$ftp_user_pass);
> 
> // take raw list files
> $contents = ftp_rawlist($ftp_id, "$path");
> 
> echo '<TABLE>';
> foreach ($contents as $key => $value) {
> 
>     $info = explode(" ", $value);
>     $clean = array();
>     foreach ($info as $key => $value) {
>         if (!empty($value)) { $clean[] = $value; }
>     } // end foreach loop 2
>   
>     if ( ($clean[8] != ".") AND ($clean[8] !=
"..")) {
>         echo '<TR>';
>         print "<TD
WIDTH="40%">$clean[8]</TD>"; //
name of file
>         print "<TD WIDTH="20%"
ALIGN="CENTER">$clean[5] $clean[6]
> $clean[7]</TD>"; // date info
>         // prep size
>         $size = $clean[4];
>         $size = $size / 1000;
>         $size = ceil($size);
>         if ($size <= 0) { $size = 1; }
>         if ($size >= 1000) { $measure =
"MB"; $size = $size /  1000; }
> else { $measure = "K"; }
>         print "<TD WIDTH="20%"
ALIGN="CENTER">$size
$measure</TD>";
> // size
>         echo '</TR>';
>     } // end if
>   
> } // end foreach loop 1
> echo '</TABLE>';
> 
> Julien
> ||
> 2007/8/13, Alexander Pelov < a_pelovyahoo.com
<mailto:a_pelovyahoo.com>>:
> 
>     Hi Emil,
> 
>     if we're able to run PHP scripts on the server,
there are some
>     existing solutions. From the ones I saw I prefer
snif (http://
>     www.bitfolge.de/snif-en.html <http://www.bi
tfolge.de/snif-en.html> -
>     see the live demo). Another example is
>     Autoindex ( http://autoindex.so
urceforge.net/).
>     Snif provides an index.php, which handles the rest
automatically.
>     I've tried it and it works like a charm (just copy
the first
>     index.php found in the zip to the dir).
> 
>     As an extra one may provide description for each of
the files. This
>     is done with the help of an additional file called
"descript.ion".
>     The rest you'll find in the index.php itself.
> 
>     Hope that helps,
>     Alex
> 
> 
>     Le 13 août 07 à 10:12, Emil Ivov a écrit :
> 
>     > Hello all,
>     >
>     > The java.net <http://java.net> team have
recently migrated their
>     download.java.net <http://download.java.net
>
>     > server
>     > from collab.net <http://collab.net> to
Sun. Among other things
>     this change has caused a
>     > problem with the download pages. We were
previously using .htaccess
>     > files to configure the auto generated
directory indexes and we were
>     > setting headers, custom icons, and column
width.
>     >
>     > Not taking into account .htaccess files has
resulted in degraded
>     > usability of these pages and they now look
like this:
>     >
>     > http://download.java.net/communications/sip-com
municator/nightly/
>     > debian/
>     >
>     > The only way to discern the different versions
is to place the mouse
>     > over them and compare the contents of the
browser status bar (imagine
>     > your grandma doing this?).
>     >
>     > This is something that we need to take care of
so I was wondering what
>     > might be the possibilities. Here are some
ideas:
>     >
>     > - Keep a single nightly build version
available for download. This
>     > would
>     > make it easier for users to choose, though the
downside is that if the
>     > latest version has serious issues that have
not been detected by the
>     > tests, it won't be possible for the user to
roll back to an earlier
>     > version
>     >
>     > - Create scripts that generate our index
files. That was what we were
>     > doing before collab.net <http://collab.net>
enabled .htaccess
>     configuration of index files
>     > on the old java.net <http://java.net>. We
could do this but it's
>     quite painstaking and
>     > error prone. Nonetheless if anyone feels like
it - don't hesitate to
>     > write some. All we need is a generic .sh file
that would use a fixed
>     > header and generate a listing based on the
contents of a directory.
>     > The
>     > problem here is that (contrary to the
collab.net
>     <http://collab.net>
version of djn) we
>     > have
>     > no ssh access on the download machine (only
sftp) so we'd probably
>     > have
>     > to keep a local copy of all the downloadable
files, generate the index
>     > over it and then make sure that it stays in
sync with the contents of
>     > the download server.
>     >
>     > - Use an existing tool for generating page
indexes. I have been
>     > looking
>     > for something like this for a while but had no
success. Is anyone
>     > aware
>     > of an open source tool that would generate
html directory listings? We
>     > still have the same problem as with the above
though - we'd need to
>     > run
>     > the tool locally and then copy the index on
the site.
>     >
>     > - Use another download server (suggestions?)
>     >
>     > Any ideas and contributions are most welcome
since we really need to
>     > find away around this.
>     >
>     > Cheers
>     > Emil
>     >
>     >
------------------------------------------------------------
---------
>     > To unsubscribe, e-mail:
>     dev-unsubscribesip-communicator.dev.java.net
>     <mailto:dev-unsubscribesip-communicator.dev.java.net>
>     > For additional commands, e-mail: dev-helpsip-
>     > communicator.dev.java.net <http://communica
tor.dev.java.net>
>     >
> 
>    
------------------------------------------------------------
---------
>     To unsubscribe, e-mail:
>     dev-unsubscribesip-communicator.dev.java.net
>     <mailto:dev-unsubscribesip-communicator.dev.java.net>
>     For additional commands, e-mail:
>     dev-helpsip-communicator.dev.java.net
>     <mailto:dev-helpsip-communicator.dev.java.net>
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi!

I am currently working on using the Sip-Communicator as a
small test
application for some customers (sometime,..). However, what
I know, is that
we need a German translation, at least of the main menu, the
contact window
and the sip-protocol wizard.

Therefore I could translate these items and post it to the
public, if anyone
is interested. I you want me to contribute, please contact
me directly using
email, and tell me, how to do this.

Best Regards
Thomas Hofer

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Thomas!

> I am currently working on using the Sip-Communicator as
a small test
> application for some customers (sometime,..). However,
what I 
> know, is that
> we need a German translation, at least of the main
menu, the 
> contact window
> and the sip-protocol wizard.
> 
> Therefore I could translate these items and post it to
the 
> public, if anyone
> is interested. I you want me to contribute, please
contact me 
> directly using
> email, and tell me, how to do this.

Incidentally, I kind of offered to do a German translation a
few days ago,
if I could find the time. It seems as if can get around it
now 

Here is a short how-to on how to do the translation. If it
is not detailed
enough, please ask. Note, however, that I am not one of the
SIP-Communicator
developers, so I am not speaking with authority.

To do the translation, you'll have to download the source
release of
SIP-Communicator (see
http://www.sip-communicator.org/index.php/Main/Download) or checkout the CVS
version (see
http://www.sip-communicator.org/index.php/De
velopment/VersionControl). Then
copy the file
'src/net/java/sip/communicator/impl/gui/i18n/messages.proper
ties' to
'src/net/java/sip/communicator/impl/gui/i18n/messages_de.pro
perties' (notice
the new name ..._de.properties). In the copied file, leave
the messages keys
(left side of the '=') alone, and replace the English text
on the right with
the German translation. The , ... are placeholders
which will be
replaced with the actual text at runtime. When you build
SIP-Communicator,
it should automatically include the German translation. If
you want to
translate the SIP account wizard as well, you'll have to do
the same
procedure with the file
src/net/java/sip/communicator/plugin/sipaccregwizz/resources
.properties.

I hope this helps.

Regards
Michael Koch

Hi Michael!
Thank you for your short how-to. However I am used to
java-programming and
how to deal with internalization. My question was not a
technical one (how
to do this, I know) but rather an organizational one, how to
contribute to
this open source project.

Best regards
Thomas

> -----Ursprüngliche Nachricht-----
> Von: Koch Michael [mailto:MKochrowa.de]
> Gesendet: Montag, 13. August 2007 17:11
> An: devsip-communicator.dev.java.net
> Betreff: [sip-comm-dev] i18n for German
> 
> Here is a short how-to on how to do the translation. If
it is not
> detailed
> enough, please ask. Note, however, that I am not one of
the SIP-
> Communicator
> developers, so I am not speaking with authority.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net