I've been playing around today with MorphUP and i'm really impressed, it's a solid piece of software, with very good features and easy to use.

I was only wondering, is there a place where all MorphUP links (.pmi) are centralized ? Each dev providing a link on forums or news is not the best thing in my opinion. If we want MorphUP to become what it deserves to be then we need a webpage or repository where all these links could be posted and updated.

Is there already such a thing or should we start thinking about it seriously ?

I can try to get a fast connection. I can speak with my universitary school director (I study computer science), and see if I can have one computer there. I think there should be not too much trouble. The only trouble, is the computer. Does the server side of morphup run on MorphOS or in linux? I can only put there a x86 machine, as I would like to use my peg at home ;). It perhaps would be nice, for a genesi blade server... If bbrv donate one, I can put it there (almost for sure).

I take this oportunity to greatly thank Rupert for materializing what was my vision for this software.

Now it is up to the users to make as many packages as possible and why not someone could create a "mother" site linking to all the index (.pmi), reporting broken links, establishing mirrors etc.

The requirements to distribute packages on the server side are really minimal : any http server.
The server will host an index of your packages and the packages.
Morphup has the ability to save a lot of bandwith when using "single" and "link" packages.

When you use "single" packages the user will download fully the application once and then it will only download the files that have been updated between releases.

When using "link" packages only the index will be downloaded from the site. The files that are making the package will be downloaded from other servers.

An example: Create an "installer" package that link to the Commodore installer on Aminet. Your package may only install the installer binary.

If you know a great software freely available on one site that requires a library in another archive (for example on aminet) you can create a an index that will takes the binaries and data file from one site an the libraries on aminet.

Morphup is not limited to software distribution, you can distribute any kind files with it. For example the Pegasos book is now available as a Morphup package.

It is not limited for people producing software. There is a lot of work to re-package existing applications which requires several elements scattered on the internet.

I hope that a lot of users will enjoy it and build up around it.

I tried to fire up discussion about it a week ago at ann.lu. I repeat myself.. how about Aminet?

Hi guys,

I've already talked with the aminet-webmasters. They say, they don't want to host whole packages (.pmp/.pmf) because of webspace. Also they don't want to have two 'systems' side by side, so lha's and morphup and they are a bit worried that people will not support the aminet (via lha's) anymore if it's hosted there.

There are two possibilities. First, each developer host his index on his private homepage or whatever and give a link to the index-file (#?.pmi). Second, we make a central portal where ervery dev can upload. The advandage of the first method is that only small webspace is needed, because every dev host the data-packages (.pmp/.pmf) for his own and just give a link to the pmi-file. Both methods need someone who manage the site, either the link-site or the upload-portal. For the second method, there must be the possibility to edit the upload at any time...

We discussed the following:
Maybe it would be possible to add a new tag to the aminet readme files, like "x-pmi: http://somewhere/index.pmi". So, each dev can give a link to his morphup-index, where the lha is included he just uploads to the aminet. Then, this x-pmi-tag is fetched by aminet, automaticaly put into a list and removed from the readme. This list is then published each day via a script... We did'nt find a optimal solution yet, so we remain that we talk again in a few days...

Anyway, for now i set up a first link site at http://morphup.atspace.com

I think a central upload portal is the right solution.
I mean, hey there is OS 4.0 Depot, Aros Archives, why shouldn`t we be able to have our own repository?
And a central point is imho a must, else the whole point of a package system is somewhat lost (at least a bit)

Agreed

I think a centralized portal would be the way to go. I'd like to say I think Morphup is one of the most important software advances for our platform, that is if the developers fully embrace it. Hopefully we will see alot of progress in the future.

magnetic

Why not just upload the archives to aminet and host the morphup .pmi on another central site?

I'm one of the Aminet admins that discussed the issue with naTmeg two days ago. I'd like to point out a few things you might want to consider when discussing this. Please note that I'm not badmouthing MorphUp (actually, I'm impressed with naTmeg's effort so far), I'd just like to explain the problems you are going to face.

MorphUp currently uses proprietary, undocumented formats and the only tools that are able to deal with these formats are the MorphUp tools. This situation creates two problems:

1. If somebody's going to host a central repository for MorphUp, he'll have to check each upload manually with MorphUp (i.e. on his local machine) and then accept or deny the upload using whatever admin tools he's got installed on the server. This is a time consuming and error prone process. There might also be legal issues (distributing GPL sources in a proprietary format?)

2. The server has no way of extracting information from a pmi file, all he knows about foo.pmi is that it is called foo.pmi. Unless you introduce an additional way of retrieving information about an upload (like forcing uploaders to upload an Aminet style *.readme file with each pmi) you can't offer any useful functionality for HTTP-Users - apart from simply listing all the packages in one single. long list.

Another problem is that MorphUp's index files (pmi) can contain information about just one single package, or lots of packages at once. Making just one single index file is both impossible (again: your server can't handle the format) and would probably result in an extremely big pmi file. Unless you enforce very strict rules ("each pmi file might only contain information about one single package") or constantly rebuild index files manually, there's no way of sorting the packages on your repository ("biz/dbase", "gfx/edit"). Just imagine itix or tokai would upload a pmi file with some or all of their packages - it would contain emulators, cli tools, cd players etc. no way to categorise said pmi file.

We're open to suggestions for solving these problems - it's not that wouldn't want to help, it's just that we can't see how we could help right now.

@DJBase:

Quote:
Because the pmi, pmp and pmf files have to reside on the same host (and in the same dir).

Additionally, we definitely can't host a format that Unix can't handle. We need to be able to verify a package's integrity and content.

[ Edited by cgutjahr on 2006/3/21 0:30 ]

Sorry, completely forgot what all that mumbling was about:

"A central MorphUp repository" will almost certainly not be like anything you have in mind (i.e. something like Aminet). This is why naTmeg's suggestion to simply collect links to individual pmi files at a central place actually make a lot of sense given MorphUp's current state.

@Bladerunner:

Quote:
/me spanks Bladerunner very hard ;)

Quote:

ouch, that hurt ;)

No honestly, You know I like Aminet, I really do :)

However imho to work properly, MorphUP need badly a central point where one can get files. Search and find files over diferent locations makes the whole effort pretty uncomfortable and it just remains a better install tool. To get it`s full power there is a place like aminet needed.
And the thing is, if Aminet can`t handle that (and I actually understand your arguments) there is need of something else/new.
However the argument for "something own" is just valid if there is no way somehow integrate MorphUp into Aminet.

Bladerunner:

Yes, the problem of tracking down files all over the net is VERY frustrating to new users. And these are the people we need. ALot of die hard amigas that get MOS know where to find these things, but the noobs have no clue and this makes their experience a hassle..

@cgatjur

Thanks for your post. Very interesting information. Though the part about the GPL - i dont know if its illegal by the distro method but isnt it if the sources are always available it fits the GPL rules??


magnetic

@Bladerunner:

Quote:
I'll try to explain it differently:

Until somebody ports the MorphUp tools to Unix or you find some people with quite some spare time (to constantly rebuild indices manually) a "central MorphUp repository" would pretty much work like this:

All MorphUp indices (i.e. pmi files) uploaded to the server would be listed on a HTML page. You click on one of the pmi files and MorphUp would download the pmi file and handle all the rest (show packages managed by that pmi, download the ones you want, install them).

What naTmeg suggests (i.e. a website that simply lists URLs to the pmi files spread across the net) would work exactly the same way: click on the pmi file you want, wait until MorphUp has loaded it etc.

Quote:
I know, I was just joking. I'm not advocating sticking with Aminet, as we can't see a way how this could work anyway.

I'm just trying to explain that for now, naTmeg's suggestion makes as much sense as anything else. You can still search for a server later on, as having a central repository doesn't have any benefits right now. At least that's how I understood MorphUp.

@magnetic:

Quote:
I'm not saying it is illegal, I have no idea if it is or not. I'm just saying that one should perhaps investigate that issue before releasing or hosting GPL sources in a custom format. The GPL does definitely make a point that access to the sources of a GPL product should be as easy as possible, and a custom format that can only be extracted on MOS doesn't fit that description.

Think about this: "I have ported OpenOffice to the Amiga. I'm going to sell it for a hundred bucks. The sources are available here, you'll need a C64 with a 400$ CPU add-on and a 20GB harddrive to extract them".

thanks guys for being involved in that topic.
thanks to you cgutjahr for clarifying a few things, it's always useful to have advices and warnings from someone that has a significant experience in file hosting.

I wasn't really thinking of a repository where all packages could be hosted, the current system with devs providing links and hosting their packages is still ok for now. The main issue is to find these links. I think we should focus on a portal providing these links.

What about collecting the links here at MZ? Okay the site has several serious flaws in the past, but anyway...

Quote:

Ok, I didn't know how MorphUp works.

A central repositry would be preferable, because when the programmer disappears the software package should remain.

@Zylesea

very good idea !!

@wishmaster

true, i was thinking about it, but that could be a second step project, not easy to do for the previously mentioned reasons.

[ Edited by SoundSquare on 2006/3/21 12:01 ]

@ naTmeg

Please check PM.

I agree with making a site that just lists the links to the devs pmi files. All you need to do is make a type pad or blogger page and give the password out to devs so they can add a link to the new list as they make them. If all thats needed is a static page with links thats a perfect solution. You can even comment on the links that way.

Take a look at my site at www.acill.com for an example. I simple use blogger to host the page. The rest is all edited by hand through a 3rd party editor and updated to blogger.

Quote:

I understand that there is an index file, which has entries pointing to files. Why can't these be in different locations? How about the possibility of having more than one location for a single entry, in order to assure its availability, if a single location fails?