I am going to develop a cloud application and in my research for state of the art tools in Cloud Computing i saw some references to OCCI (Open Cloud Computing Interface).
I was not able to find out an answer to the following questions
1)Is it easy to use this Interface ?
2)What programming languages does this interface Supports ?
3)Is this Interface mature enough?
Any information are well appreciated!
This question has been asked quite some time ago but, hopefully, the answer is still relevant.
Is it easy to use?
Depends on what you want. If you want to make your own implementation, then probably not. If you use one of the existing implementations (see bellow), then yes.
What programming languages does this interface Support?
We know about two implementations (libraries, CLI), which are for Ruby and Java. See:
https://wiki.egi.eu/wiki/rOCCI:ROCCI
https://github.com/EGI-FCTF/jOCCI-api
rOCCI (the first one) also as a server side (the rOCCI-server) that translates OCCI to propriatary cloud management platforms such as OpenNebula.
Is this Interface mature enough?
Yes, given that it is being used by real-world infrastructures. Among them, e.g., the EGI Federated Cloud. That said, the current OCCI specification (1.1) has a few shortcomings that will be addressed in version 1.2 (due in Autumn 2015), so that if someone is just starting a project, it is worth implementing with 1.2 already.
Many of your questions can be answered (positively, by the way!) by visiting the OCCI-WG home site at http://occi-wg.org and/or searching on "occi implementation".
Another recent and useful resource is the tutorials and workshop talks given at the recent Cloud Interoperability Week held simultaneously with events in Madrid and Santa Clara, part of the Cloud Plugfest hands-on developer training series:
Or generally at http://www.cloudplugfest.org/
The basic specs are published by the Open Grid Forum.
The Open Cloud Computing Interface (OCCI) is a set of specifications delivered through the Open Grid Forum, for cloud computing service providers. OCCI has a set of implementations that act as proofs of concept. It builds upon World Wide Web fundamentals by using the Representational State Transfer (REST) approach for interacting with services.
Related
I need to implement solution with add-ins executed in their AppDomain. I came across MAF, which is - by description - what I needed.
However the documentaion and its CodePlex project seems to be a bit outdated, some pages in docs do not exist for "Current version" of .NET.
I also found posts about gotchas and complexity of MAF.
So I'm now not sure if I should use it or rather do all the work by myself (add-in management, loading/unloading AppDomains, etc).
Any thought and/or experience appreciated
MAF is a supported piece of the .Net framework, but it hasn't received much attention in years.
Pros
Supports out of process/app domain loading of Addins
Supports backward compatibility for AddIns
Cons
Complex (Requires 5 DLLs in the pipeline)
Requires investment in tooling (You need to update/maintain your own copy of the Pipeline generation code)
Hasn't received any updates in functionality since it was released
There is not a lot of information on the web on best practices or issues people have run into
While there are more cons in that list, it does work and mostly does what you expect. My suggestion is to try it out and see how it works. At the end of the day, the consumers of your API are using an interface and you can always swap out the MAF layer in the future and your AddIns wouldn't need to change.
I am aware that this may potentially be an unsuitably broad question, but I am unsure where else to ask about it. Hopefully it can serve as a basis for information for me and other seeking to construct richer web applications.
I am very interested interested in the availability of frameworks that ease the construction of rich web "desktop" apps. The best single example I can think of is AirDroid (demo: http://web.airdroid.com/). I have tried to deduce from studying the HTML and JS itself what it is built by, but it all appears to be proprietary.
If I want to construct something similar in a robust fashion, what are some mature, open source technologies, libraries and frameworks I should be looking into?
I have found at least one framework with the necessary features for implementing the kind of system asked for in the question.
os.js is a Javascript framework with a "web desktop implementation for your browser with a fully-fledged window manager, Application APIs, GUI toolkits and filesystem abstraction.". As such, it has the essential features needed to craft a rich desktop environment, along with an underlying toolkit helping to tie it to backend functionality.
This is a good, extendable starting for crafting more basic solutions.
Reference:
http://os.js.org/
I am looking at a powerbuilder 11.5 application modernization. I think I would want to Web Service enable the powerbuilder server and rebuild the client in HTML verusus re-write the entire stack (its over 1.8M lines of code). Does anyone know if WebMethods or a similar ESB can interface and abstract a powerbuilder server?
I did some research on modernizing Powerbuilder and discovered with this particular version (and I suspect others) it is not trivial.
PowerBuilder modernization is difficult because:
it is based on a client/server architecture, so the UI is compiled and deployed to a users machine
all of the business logic is locked up in a language that is not portable to other platforms: PowerScript
PowerScript runs in its own proprietary virtual machine: PBVM.
Sybase provides strategies and methods to move to a distributed, web-based J2EE platform (their EAServer), or .NET. Both approaches come with lots of caveats, considerations, pros, and cons. A good example is that in PowerBuilder, developers can put code in visual object (like attached to an onEvent of a button), but when moving to an n-tiered environment this logic needs to reside on the server in a non-visual object (NVO). This would allow relatively simple event interaction that could be captured and modernized even though it will really require a good deep look at all of the interfaces and some code insertion which needs to be carefully monitored.
A paper that explores some of the steps and considerations for moving to their EAServer:
http://www.sybase.com/sb_content/1020364/PBtoEAS_7steps_v2.pdf
I am looking at using some Dataflow programming techniques in a clojure program but I am having difficulty in finding much information from projects using Java, C#, or other mainstream languages that have used such techniques in the real world. I would be grateful to hear if anyone has any expereinces they could share regarding this.
Here, we are! We've made... (quotation is from one of my older post):
We've designed and implemented a DF
server for our automation project
(dispatcher, component iterface, a
bunch of components, DF language, DF
compiler, UI). It is written in bare
C++, and runs on several Unix-like
systems (Linux x86, MIPS, avr32 etc.,
Mac OSX). It lacks several features,
e.g. sophisticated flow control,
complex thread control (there is only
a not too advanced component for it),
so it is just a prototype, even it
works. We're now working on a
full-featured server. We've learnt lot
during implementing and using the
prototype.
Also, we'll make a visual editor some
day.
There're dataflow systems wich don't even mention dataflow approach:
SynthEdit: http://www.synthedit.com/ - It's an audio related framework and component set for creating VST plugins
TinyOS: http://www.tinyos.net/ - It's an embedded operating system/framework
Digital synthetisers/samplers are dataflow systems, programmed - supposedly - in C or some parts in Assembly, check my answer to another post about some examples.
Quartz Composer, a graphic magic tool for Mac,
Blender has dataflow subsystem for image composing.
Writing a dataflow system is not rocket science. Here's my older post about the basics of dataflow framework.
The term dataflow is wide. There are realtime synchronous dataflow systems, like synthetisers and samplers, there are asynchronous ones, like our home aut. system (the system is in idle unless the user presses a button or a timer runs out), and there're even different architectures, like spreadsheets or make.
Wanna reading more about dataflow programming? Read J. Paul Morrison's site and book.
Pervasive DataRush is a framework for parallel dataflow programming for any JVM language, including Clojure.
Pervasive DataRush uses a dataflow architecture. The architecture implements a program that executes as a graph of computation nodes interconnected by dataflow queues. The nodes use the queues to share data. As the data is streaming, only data required by any active operation needs to be in memory at any given time, allowing very large data sets to be analyzed. Besides offering the potential for scaling to problems larger than available memory, dataflow graphs exploit multiple forms of parallelism.
Customers are using DataRush for big data analytics and data preparation (ETL).
We've made another one: a collaborative spreadsheet with MySQL/PHP backend and AJAX frontend. The software is in beta state, documentation is under construction.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
We're thinking of moving from our existing installation of MediaWiki to something more feature-rich. I'm trying to find all the pains people have with MediaWiki today (mainly it's poor handling of external documents and less-than-perfect editing capabilities - compared to Word).
We are using a wiki for design, spec, process guidelines. We have several external documents (docs, powerpoints) that we are currently putting on a shared folder and linking to from the wiki (because uploading files is not very convenient in MediaWiki).
We are trying to make the friction minimum, so that nobody will have an excuse or reason for not using it.
Some options we're considering are Confluence, Trac & Sharepoint. Money is not a big concern, only ease of use (and maintenance) and feature-fullness. What would you use?
I would plug the details of my specific feature needs into the excellent WikiMatrix choice wizard and let it make recommendations.
I would advise either
Foswiki ( http://foswiki.org ), (forked by the whole developer community of TWiki to avoid trademark threats), for a feature-rich and fully open programmer's wiki. Drop on #foswiki on irc.freenode.net to chat with the community.
Mindtouch's Deki Wiki ( http://www.mindtouch.com/ ) clearly the most user-friendly advanced and innovative wiki out there, a modern commercial + open source offering. Great integration with Office docs.
I would avoid Confluence. Confluence made a design choice (forbidding mixing html in pages with Wiki syntax) that proves deadly to any attempt at wysiwyg, as it uses a standard HTML editor for WYSIWYG, and this converts it on save in a very limited subset of it, yielding frustrating surprises for the users (foswiki for instance keeps as html the parts the wiki syntax do not handle like bullet lists in table cells). Confluence have many great sides, notably its integration with atlassian great tools as their JIRA bugtracker, (we use it at work for this with good results) but do not plan to customize it.
There are many good choices on hosted wikis too (Google sites, based on the awesome jotspot engine is one).
Never use Sharepoint of course. Its wiki capabilities are a IE-only joke, and Sharepoint whole architecture is braindead (storing all data - even huge docs - in a non-distributed database goes against Microsoft own recommendations). If you want a DMS with good Office integration, have a look at KT (Knowledge Tree) instead. http://www.knowledgetree.com/ . For political reasons we were forced to use Sharepoint at work but we limited it to basic document managing (never use the MOSS higher layer, as it breaks compatibility between versions) and integrated a foswiki frontend to it (dumped document list & metadata in xml and provided navigation in foswiki, and search with a google box)
But my real advice would be to ... wait for Google wave, that promises to revolutionize the wiki concepts.
Disclaimer: I am part of the foswiki community.
Before you move away from Mediawiki I would urge you to consider the many extensions available. IMO there arent many wikis that offer more features that MW, especially when you consider the number of extensions. See http://www.mediawiki.org/wiki/Category:Extensions
For example, for editing there are browser based editors similar to Word. And there even macros for Word that allow you to export from MS Word to your Wiki, from within Word.
Also, check out the Semantic Mediawiki extensions. These give enormousness benefits in the area of Knowledge Management.
I would personally recommend against moving from Wiki to SharePoint. The huge problem there is SP's dreadful handling of images.
First of all I would stay away from Sharepoint. Period.
I would not consider switching to Trac either, since Trac has special focus on issue tracking, and poor support for external documents.
I would consider switching to Confluence, since:
Money is not an issue (as you said)
You want to minimise maintanance work (as you said)
You want to use wiki to handle external documents (as you said)
I'm typically a strong advocate of open source technology, but with the requirements you gave, I just don't think they would make you happy. For instance if you had personnel available for maintaining and providing customisations to your system, I would definitely suggest trying out Foswiki, which also would otherwise fit your needs very nicely. However, if you really want to stay away from any extra maintance work, Foswiki is not a good option.
I work on Tiki Wiki CMS Groupware and I'll share a few links. This question comes up quite a bit so we have a dedicated page: http://tiki.org/Tiki+vs+MediaWiki
We're thinking of moving from our existing installation of MediaWiki
Tiki & MediaWiki are both PHP/MySQL so you can use the same server.
Tiki has a built-in importer: http://doc.tiki.org/MediaWiki+importer
to something more feature-rich.
Tiki is the http://tiki.org/FOSS+Web+Application+with+the+most+built-in+features
We are using a wiki for design, spec, process guidelines. We have several external documents (docs, powerpoints) that we are currently putting on a shared folder and linking to from the wiki (because uploading files is not very convenient in MediaWiki). We are trying to make the friction minimum, so that nobody will have an excuse or reason for not using it.
http://doc.tiki.org/WYSIWYG
http://doc.tiki.org/File+Gallery (instead of your shared folder)
http://doc.tiki.org/Docs (web-based ODFs)
http://doc.tiki.org/Spreadsheet (web-based)
http://doc.tiki.org/Slideshow (web-based)
http://doc.tiki.org/Draw (web-based)
Some options we're considering are Confluence, Trac & Sharepoint. Money is not a big concern, only ease of use (and maintenance) and feature-fullness. What would you use?
Tiki is Free/Open Source. But if you have money burning your pockets :-)
http://tiki.org/Donation
You can also hire a consultant to provide training/support and to accelerate the implementation and/or sponsor feature development
http://info.tiki.org/Consultants
Have you considered sharing your Word documents with Google Docs? It has revision control and collaboration features like a wiki, as well as a rich text editor that can import and export plenty of formats.
It sounds like TWiki would be a great option for you as well. I haven't used it myself, but it also has a rich text editor, as well as tons of enterprisey project management features in it.
A lot of people seem to like Confluence. I personally don't know it. If you are not already at it and you want something feature-rich than xwiki could be something for you.
I'd add FCK Editor for WYSIWYG, get a decent document management system to run alongside the wiki and carry on with MediaWiki!