Announce Script Feature / Plugin

[definate 0]

A really good feature would be the development of an announce script feature/plugin that announced new files when they are hashed.

For instance, I am regularly getting new downloads put into several different folders, when new downloads go into them, I either need to tell people in the server chats or private messages that I now have new stuff, or they need to go and check in these folders for new files. It would be good to have the ability to announce it to several channels or similar, and perhaps have a RSS feed which could trigger downloads. (Just brain storming here) The only problem I see would be in ensuring that when hashing a new share, these are not announced, else you are likely to flood the channel.

I am getting these ideas from the large communities around FTP sites and Torrent sites. These sites help people mass share new things by informing people of new things, and making it easy to automate transfers. The more this could be done on DC the more DC would become a de facto standard for sharing.

Either way, it would really help for the few small communities I participate in, and I'm sure many other people would find this really handy.

What does everyone think?

[Guest Toast]

Voted yes on the first but i wanna say as a plugin

Voted no on the other one since i know there is a ext being developed for ADC on FEED

[Yeppy 0]

i voted no for both since i don't think it is really necessary to let everyone now in the hub that i have added something in to my share. if i really need to tell them then i tell them i have new stuff so they can check my filelist. imagine what this could be in a rather big hub where there's always something new added to someone share.

for hte second part i also think it is somehow useless because come on what's next ? gonna ask apex to cook your dinner ? don't try to push the client too far but rather try to keep it simple.

[definate 0]

i voted no for both since i don't think it is really necessary to let everyone now in the hub that i have added something in to my share. if i really need to tell them then i tell them i have new stuff so they can check my filelist. imagine what this could be in a rather big hub where there's always something new added to someone share.

for hte second part i also think it is somehow useless because come on what's next ? gonna ask apex to cook your dinner ? don't try to push the client too far but rather try to keep it simple.

Okay, this would be an optional plugin or setting, so if you don't want it, don't use it.

What this feature(s) would be doing is emulating the extremely popular features of people who run proper FTP sites and Torrent sites. In a rather big hub you do like they do on rather big sites, and you have a channel dedicated to announce scripts only. This way that window has all of the announce information, and you can track it easily, without interrupting conversation. Or, as I said before, you turn it off.

No, we don't want Apex to cook our dinner, although they might be good at it. What I was referring to was elevating DC to the more professional file sharing level. This will generate a lot wider adoption of the protocol.

The DC community needs to keep innovating servers and clients to make them easier, more efficient, and competitive with the features of other solutions.

Thanks.

[patch1 0]

To see what is new I think I would prefer drop down menu in the file list screen enabling ready display of changes since I last looked at that file list. As described http://forums.apexdc.net/index.php?s=&...ost&p=22114

The reason is an automatic system would be spammed by minor changes to the shared files. For example changing the genre or album art for several mp3 albums would trigger lots of low value traffic. Renaming a root directory may also generate lots of messages depending how the software was written.

BTW

I fully support some way of readily finding out about newly shared files on small hubs. I suppose I just have little experience with the solutions you propose.

[baba.runner 0]

I voted no on both, as I think that both do belong to the hub part and not to the client part of DC.

A Hubowner does not necessarily want that "normal" user can post things on his hub without his acknowledgement.

For the RSS-feed, there are other possibilities to have that information. It would be OK if the Feeds were only in relation to APEXDC++ and only visible for the user of the client. And those information are already available here.

[definate 0]

To see what is new I think I would prefer drop down menu in the file list screen enabling ready display of changes since I last looked at that file list. As described http://forums.apexdc.net/index.php?s=&...ost&p=22114

The reason is an automatic system would be spammed by minor changes to the shared files. For example changing the genre or album art for several mp3 albums would trigger lots of low value traffic. Renaming a root directory may also generate lots of messages depending how the software was written.

BTW

I fully support some way of readily finding out about newly shared files on small hubs. I suppose I just have little experience with the solutions you propose.

The automatic system is still voluntary, so it requires you to turn it on. Additionally, most people download to a few specific directories, sometimes just 1 specific directory. This means that "newly shared files" can be limited to files that have entered this directory. When a file is moved, it is easy to find, by searching for its name or by rifling through the hierarchy, so this information need not be announced.

To reduce the flood of traffic, the information could be specified to be announced to a #annouce (for instance) channel, where only this information is passed on. This makes it quite easy to either ignore the information, or passively monitor it. Additionally, it allows new files to move faster throughout the network, which can help people race for quota and similar.

This feature could greatly improve the efficiency of DC as a sharing medium of 0sec / 0day files.

[definate 0]

I voted no on both, as I think that both do belong to the hub part and not to the client part of DC.

A Hubowner does not necessarily want that "normal" user can post things on his hub without his acknowledgement.

For the RSS-feed, there are other possibilities to have that information. It would be OK if the Feeds were only in relation to APEXDC++ and only visible for the user of the client. And those information are already available here.

As far as I know, hub's are not sent information on files that have been hashed. They merely allow communication between 2 peers, and facilitate regulating the sharing. That means a feature such as this could not be implemented on the hub side. (Someone please correct me if I'm wrong about this, as if the hub does know about all files hashed, this would be a much easier implementation method)

This sentence "A Hubowner does not necessarily want that "normal" user can post things on his hub without his acknowledgement." makes no sense.

Are you talking about hub owners not necessarily wanting normal users sending messages on his hub without his acknowledgement? If so, he can regulate this using the restrictions on creating a channel, or restrictions on who can message to the channel, and more advanced hubs could even regulate what is said by kicking them based on incorrect information.

Or are you talking about hub owners not necessarily wanting normal users sharing files on his hub without his acknowledgement? If so, this goes against everything that the DC is setup for, so I don't think ANY hub owner would want this.

Since these are the only two things either of these plugins would be doing (though the RSS plugin would be purely peer 2 peer communication).

The RSS feed would be using either the direct connect protocol to send and recieve an xml file with the data, which is interpreted, or it could use http to be backwards compatible with other aggregators. Either way, it would be a good idea. Having it built into Apex DC++ through a plugin, like Azureus, uTorrent, and all the popular torrent clients.

However, I believe the announce script would be easier as it only requires Apex DC++ and could probably be done in a plugin. This way it could be developed quickly and put into circulation so people can start benefitting from it.

[patch1 0]

To reduce the flood of traffic, the information could be specified to be announced to a #annouce (for instance) channel, where only this information is passed on. This makes it quite easy to either ignore the information, or passively monitor it. Additionally, it allows new files to move faster throughout the network, which can help people race for quota and similar.

The problem with an automated system is it would tend to broadcast detail and not concepts.

For example if a shared a new album with 20 mp3 songs, would that generate 20 new release messages

Or if a shared a movie with 40 par files would that generate 40+ new release messages.

If I renamed a high level directory that may generate 1000's of new release messages (unless there is the facility to restrict monitoring to a subset of the share and I'm carefull to not rename folders within this share) - ??complexity and error prone by naive users.

A possible solution would be only broadcast the highest level directory which was new (so only announce the folder containing the album or movie, not the individual files). Coding this maybe more difficult though as files a added and hashed one at a time. Some sort of time out would be needed to ensure a further files were not being added to the set, prior to additions being announced.

[Sergeo7 1]

I think the API subsystem must be updated further to implement this idea by supporting such things as custom(i.e. plugin provided) command line options or some interface to existing, item custom menus/custom toolbar buttons, custom webserver pages, possibility to add/remove downloads via API (it's possibly unsafe idea, but still) etc. For example there will be the following way:

1. User select newly added directories in share manager and call custom menu item "Add to feed", which calls dialog for the feed element description;
   
2. Plugin parse marked directories, generate short download links and put them on it's web server page/RSS output (there may be even some external php or other RSS/news aggregator to put together releases from different clients); Those links can look like this: adc://just.hub.addr/UserName?dl={ReleaseShortLink}. Maybe there is a way to use existing magnets system for this, directory magnet links for example.
   
3. User open ApdexDC webserver page and click on those short links or use some external aggregating resource;
   
4. The client (it will connect to hub if needed) recognize this link and put associated directory to the download queue.
   

For now there are no possible solutions for this within apexdc plugins idea.

And for finding newest files automatically client certainly must support source file creation timestamps in a file list. But this idea somehow unpleasant to the developers of apexdc/strongdc.

[benb 0]

I say yes to both of these however for the first one I would say prepare the message and then give the user an option somewhere to select which announces to send... otherwise you will likely flood chat. Also I agree about the automation... the more the better!